Question about redmine

[Peter Boy]

Hi,

we are using redmine as our project management tool and installation and maintenance is a
bit cumbersome. Having a Fedora package would make it a lot easier. Has someone already
tried to create a Fedora package of Redmine? Or are there specific issues that make it
difficult to create a rpm? 

I'm wondering that no rpm distribution includes a Redmine package. There is a third
party package, but it is non-functional.


Thanks 
Peter

[Vít Ondruch]

Hi Peter,

I have not heard about Redmine packaging for ages.

I think that the problem is typically the amount of dependencies, but 
probably mainly the compatibility. If Redmine is built on top of Rails, 
it is using some specific version. So having Redmine in Fedora would 
likely block update of Rails. Just looking at GH, it seems that while 
the development version is using Rails 6.1.4.4, we have already Rails 
7.0, but the stable version is using Rails 5.2.

With some bundling, that would be probably doable, but so far nobody 
picked up the ball.


Vít


Dne 28. 01. 22 v 10:31 Peter Boy napsal(a):
>  Hi,
>
>  we are using redmine as our project management tool and installation and maintenance is a
> bit cumbersome. Having a Fedora package would make it a lot easier. Has someone already
> tried to create a Fedora package of Redmine? Or are there specific issues that make it
> difficult to create a rpm?
>
>  I'm wondering that no rpm distribution includes a Redmine package. There is a third
> party package, but it is non-functional.
>
>
>  Thanks
>  Peter
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Benson Muite]

Redmine is very configurable. Might it be possible to automate 
deployment, for example with Ansible, Puppet or other similar tools? 
This may be easier to use for your purposes.

On 1/28/22 2:01 PM, Vít Ondruch wrote:
>  Hi Peter,
>  
>  I have not heard about Redmine packaging for ages.
>  
>  I think that the problem is typically the amount of dependencies, but 
>  probably mainly the compatibility. If Redmine is built on top of Rails, 
>  it is using some specific version. So having Redmine in Fedora would 
>  likely block update of Rails. Just looking at GH, it seems that while 
>  the development version is using Rails 6.1.4.4, we have already Rails 
>  7.0, but the stable version is using Rails 5.2.
>  
>  With some bundling, that would be probably doable, but so far nobody 
>  picked up the ball.
>  
>  
>  Vít
>  
>  
>  Dne 28. 01. 22 v 10:31 Peter Boy napsal(a):
> > Hi,
> >
> > we are using redmine as our project management tool and installation 
> > and maintenance is a bit cumbersome. Having a Fedora package would 
> > make it a lot easier. Has someone already tried to create a Fedora 
> > package of Redmine? Or are there specific issues that make it 
> > difficult to create a rpm?
> >
> > I'm wondering that no rpm distribution includes a Redmine package. 
> > There is a third party package, but it is non-functional.
> >
> >
> > Thanks
> > Peter
> > _______________________________________________
> > ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
> > To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail]... 
> >
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>  
>  _______________________________________________
>  ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>  To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>

[Peter Boy]

Hi,

>  Redmine is very configurable. Might it be possible to automate 
>  deployment, for example with Ansible, Puppet or other similar tools? 
>  This may be easier to use for your purposes.
>  
>  On 1/28/22 2:01 PM, Vít Ondruch wrote: 
installation currently requires a lot of development tools, including gcc (needed for
native components of some gems). And I don't like development tools on a production
server (well, I could uninstall the development tools afterwards as part of Ansible
playbook, hm).

[Vít Ondruch]

Dne 28. 01. 22 v 14:10 Peter Boy napsal(a):
>  Hi,
>
> > Redmine is very configurable. Might it be possible to automate
> > deployment, for example with Ansible, Puppet or other similar tools?
> > This may be easier to use for your purposes.
> >
> > On 1/28/22 2:01 PM, Vít Ondruch wrote:
>  installation currently requires a lot of development tools, including gcc (needed for
> native components of some gems). And I don't like development tools on a production
> server (well, I could uninstall the development tools afterwards as part of Ansible
> playbook, hm).
>  

I have the same view (I don't have gcc on my computer, just FYI), 
therefore I always use as many system gems as possible and combining 
with their upstream versions where necessary. So if there was some 
additional gem with binary extension needed, I'd probably opt to package 
it for Fedora.


Vít

[Peter Boy]

Hi Vit,

thanks for the info. I'm still considering packaging Redmine. There are not so many,
really free project management software options. Personally, I never did development in
Ruby,  but a student of mine is a big Ruby fan. So the Ruby side is doable. 

I don't want to take up too much of your time, but regarding the Fedora side, I would
probably need information. Currently, I have 2 questions:

Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not be
installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package
restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs
or development environments? (In Java, we install several JVM versions in parallel and
each program can pick a fitting one). 

In Java there are a lot of dependency (and version) issues, too. This leads to quite
elaborate spec files and version tracking, and a lot of work. So I'm used to it to
some extent. 

Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific version
specifications, likely as outdated as rails is. If I understand bundler correctly, I can
store those gems in ~/vendor and make everything private to Redmine. Is that the proper
way? Or what is the proper Fedora way?


Thanks
Peter

[Pavel Valena]

On Fri, Jan 28, 2022 at 2:06 PM Peter Boy <pboy(a)uni-bremen.de&gt; wrote:
>  Hi Vit,
>
>  thanks for the info. I'm still considering packaging Redmine. There are not so many,
> really free project management software options. Personally, I never did development in
> Ruby,  but a student of mine is a big Ruby fan. So the Ruby side is doable. 
Hello,

I can try building it in COPR[1], if you'd be interested in
collaboration. I think it would be better to handle everything in COPR
though (I'm the maintainer of RoR; building RoR in COPR regularly[2]).
We can build it together with Rails (even with 6.1.x) in one repo, but
only in F35[3] life-cycle, because F36 will have 7.0 already. Maybe it
would be easier to maintain it for something like epel-8 or epel-9
(you can build that in COPR too), as there're no rails there (we can
build those). But some manual/upstream Ruby fixes would be required.

[1] https://docs.pagure.org/copr.copr/user_documentation.html
[2] https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/
[3] https://src.fedoraproject.org/rpms/rubygem-rails/blob/f35/f/rubygem-rails...

>  I don't want to take up too much of your time, but regarding the Fedora side, I would
> probably need information. Currently, I have 2 questions:
>
>  Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not
> be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package
> restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs
> or development environments? (In Java, we install several JVM versions in parallel and
> each program can pick a fitting one). 
Ruby does not have parallel installations of Ruby, apart from modules.
It itself would need to be packaged as a module (this can be done in
COPR also). But from my experience compatibility across versions of
Ruby (at least the latest ones) is quite good, so I would try running
it with 3.0.

>  In Java there are a lot of dependency (and version) issues, too. This leads to quite
> elaborate spec files and version tracking, and a lot of work. So I'm used to it to
> some extent.
>
>  Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific
> version specifications, likely as outdated as rails is. If I understand bundler correctly,
> I can store those gems in ~/vendor and make everything private to Redmine. Is that the
> proper way? Or what is the proper Fedora way? 
Running it with Rails 5.2 would be possible, but in Fedora installing
anything to ~/vendor goes against the packaging. The philosophy is to
build all the dependencies that would be installed by bundler as RPMs
instead. There's some level of automation, but the issue is
maintainability and stability (running tests). If you're not
interested in running the tests, the stability gets much worse, but
it's much easier to maintain - so ideally there would be some balance;
running in COPR is ideal for that, in the beginning at least -
avoiding package reviews; all the tests fixes etc.. Also there's some
overhead for maintaining modules (esp. bigger ones), so I'd prefer to
avoid that.

Let me know if you're interested.

Regards,
Pavel

>  Thanks
>  Peter

[Vít Ondruch]

Dne 28. 01. 22 v 16:18 Pavel Valena napsal(a):
>  On Fri, Jan 28, 2022 at 2:06 PM Peter Boy <pboy(a)uni-bremen.de&gt;
> wrote:
> > Hi Vit,
> >
> > thanks for the info. I'm still considering packaging Redmine. There are not so
> many, really free project management software options. Personally, I never did development
> in Ruby,  but a student of mine is a big Ruby fan. So the Ruby side is doable.
>  Hello,
>
>  I can try building it in COPR[1], if you'd be interested in
>  collaboration. I think it would be better to handle everything in COPR
>  though (I'm the maintainer of RoR; building RoR in COPR regularly[2]).
>  We can build it together with Rails (even with 6.1.x) in one repo, but
>  only in F35[3] life-cycle, because F36 will have 7.0 already. Maybe it
>  would be easier to maintain it for something like epel-8 or epel-9
>  (you can build that in COPR too), as there're no rails there (we can
>  build those). But some manual/upstream Ruby fixes would be required.
>
>  [1] https://docs.pagure.org/copr.copr/user_documentation.html
>  [2] https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/
>  [3] https://src.fedoraproject.org/rpms/rubygem-rails/blob/f35/f/rubygem-rails...
>
> > I don't want to take up too much of your time, but regarding the Fedora side, I
> would probably need information. Currently, I have 2 questions:
> >
> > Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must
> not be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package
> restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs
> or development environments? (In Java, we install several JVM versions in parallel and
> each program can pick a fitting one).
>  Ruby does not have parallel installations of Ruby, apart from modules.
>  It itself would need to be packaged as a module (this can be done in
>  COPR also). But from my experience compatibility across versions of
>  Ruby (at least the latest ones) is quite good, so I would try running
>  it with 3.0.
>
> > In Java there are a lot of dependency (and version) issues, too. This leads to quite
> elaborate spec files and version tracking, and a lot of work. So I'm used to it to
> some extent.
> >
> > Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific
> version specifications, likely as outdated as rails is. If I understand bundler correctly,
> I can store those gems in ~/vendor and make everything private to Redmine. Is that the
> proper way? Or what is the proper Fedora way?
>  Running it with Rails 5.2 would be possible, but in Fedora installing
>  anything to ~/vendor goes against the packaging. The philosophy is to
>  build all the dependencies that would be installed by bundler as RPMs
>  instead.
>  

I'd say this philosophy was overcome. While noble (and don't get me 
wrong, I very much like it and obey it whenever possible), that might be 
one of reasons why we don't have Redmine in Fedora.

So I believe that for this reason, the bundling policy was relaxed quite 
some time ago and it would be reasonable for this case, if used wisely. 
I.e.

* use as many system gems as possible and vendor only where inevitable 
and as a last resort

* make sure we strive to improve the compatibility and remove the need 
for bundling

BTW, bundle everything and remove incrementaly is also good start, 
because in the mean time, the incentive is working application. I have 
seen too many failures when everything was attempted to be unbundled 
from beginning.



Vít

[Peter Boy]

Sorry for my late response! The mixture of weekend, time zones, children and corona are
becoming a considerable challenge at times.

>  Am 28.01.2022 um 16:18 schrieb Pavel Valena
> <pvalena(a)redhat.com&gt;:
>  I can try building it in COPR[1], if you'd be interested in
>  collaboration. 
I am very interested in cooperation and would appreciate it a lot! I could certainly learn
a lot. I have developed in several programming languages, but never in Ruby. And I have
built rpms, but never in the Fedora infrastructure. 


>  I think it would be better to handle everything in COPR
>  though (I'm the maintainer of RoR; building RoR in COPR regularly[2]).
>  We can build it together with Rails (even with 6.1.x) in one repo, but
>  only in F35[3] life-cycle, because F36 will have 7.0 already. Maybe it
>  would be easier to maintain it for something like epel-8 or epel-9
>  (you can build that in COPR too), as there're no rails there (we can
>  build those). But some manual/upstream Ruby fixes would be required. 
As I get it, we would start in COPR with source rpm. I set up a tiny virtual machine on
one of our public servers to create a shared available space to build Redmine and to
create a first source rpm. I would be happy to send you the access data and my doc for it
as PM. And maybe we can find a time between our time zones where we can talk via chat (I’m
living in Germany, UTC+1). The VM is not there for anything else. So nothing can break.


>  Ruby does not have parallel installations of Ruby, apart from
> modules.
>  It itself would need to be packaged as a module (this can be done in
>  COPR also). But from my experience compatibility across versions of
>  Ruby (at least the latest ones) is quite good, so I would try running
>  it with 3.0. 
I'm a bit hesitant to deviate from the upstream project specification for a production
installation. The gemfile explicitly requires Ruby <=2.7x and Rails 5, even in the
latest stable branch. And I would like to do this for Epel. As far as I know, a Ruby 2.x
is used there.

In a next step an "early bird" version would be interesting, with Ruby 3 and
either with the latest stable branch or even trunk.  

We should try to contact the project what they are thinking ab that.


>  
>  Running it with Rails 5.2 would be possible, but in Fedora installing
>  anything to ~/vendor goes against the packaging. The philosophy is to
>  build all the dependencies that would be installed by bundler as RPMs
>  instead. There's some level of automation, but the issue is
>  maintainability and stability (running tests). If you're not
>  interested in running the tests, the stability gets much worse, but
>  it's much easier to maintain - so ideally there would be some balance;
>  running in COPR is ideal for that, in the beginning at least -
>  avoiding package reviews; all the tests fixes etc.. Also there's some
>  overhead for maintaining modules (esp. bigger ones), so I'd prefer to
>  avoid that. 
I know a similar problem from Java.

I have tried a little bit. A larger number of gems that are collected with bundler are
also available with the 2.7 module as rpm. Unfortunately, especially rails and also red
carpet (for Markdown wiki pages) are not. I’ll check in detail which gems are available as
rpm and make a list. And then we would have to decide on the rest.

>  Let me know if you're interested. 
Yes, I’m very much   :-)


Best
Peter

[Vít Ondruch]

Dne 28. 01. 22 v 14:04 Peter Boy napsal(a):
>  Hi Vit,
>
>  thanks for the info. I'm still considering packaging Redmine. There are not so many,
> really free project management software options. Personally, I never did development in
> Ruby,  but a student of mine is a big Ruby fan. So the Ruby side is doable.
>
>  I don't want to take up too much of your time, but regarding the Fedora side, I would
> probably need information. Currently, I have 2 questions:
>
>  Current Redmine requires Ruby 2.7. It’s a module in Fedora 35. As a module, it must not
> be installed in parallel with current 3.0 (or 3.1 in F36). So, would a Redmine package
> restrict the complete installation to Ruby 2.7? Or would conflict with other Ruby programs
> or development environments? (In Java, we install several JVM versions in parallel and
> each program can pick a fitting one).
>  

Right, only single version of Ruby can be installed at time. While other 
ecosystems choose to support multiple versions it is not our case and it 
is on purpose. Maintaining several versions of Ruby is problematic (and 
I can't say that the modular versions get enough attention) and it would 
be even more problematic to maintain the whole ecosystem. We just 
finished mass rebuild and we needed to build 108 binary components, all 
these components would need to have their Ruby specific version in module.

BTW I think that Ruby itself might not be the limiting factor. Upstreams 
typically choose some official version just to reduce support matrix. 
For example Vagrant, the other prominent Ruby project in Fedora 
officially supports just Ruby 2.7, but it runs on Fedora just fine 
(although I have not tested it after the mass rebuild yet ;) ).


>  In Java there are a lot of dependency (and version) issues, too. This leads to quite
> elaborate spec files and version tracking, and a lot of work. So I'm used to it to
> some extent.
>
>  Redmine 4.2 needs rails 5.2, indeed. And in gemfile there are mostly very specific
> version specifications, likely as outdated as rails is. If I understand bundler correctly,
> I can store those gems in ~/vendor and make everything private to Redmine. Is that the
> proper way? Or what is the proper Fedora way?
>  

Well, yes, probably. We don't have any precedent. But should it be me, 
I'd be thinking about using mix of vendored gems, such as Rails, but I'd 
try to stay with as much as possible system gems.

BTW I'd also start in Copr and I'd be fine to stay there. Because I'm 
not sure I'd want to undergo review of such package ...


Vít