Hey guys,

Long time lurker, who wants to try and get more involved with Stephen's shifting responsibilities.  Is there a "getting started" or "hey new guy don't E-mail the mailing list" approach to contributing to this?  I've heard Stephen refer to a COPR every now and then -- I'm aware of the COPR at [1] which I forked into my own COPR, and then also the wiki [2] with basic information on actually using Node.JS in Fedora.  The packaging Node.JS page [3] looks severely outdated, since we are now no longer attempting to RPM package each individual NPM dependency and instead using that built in process?  (That was a question)

The other part I'm confused on is that the COPR shows the build was triggered by a SRPM that was uploaded [4], but then also refers to a git repository at [5] 

I wanted to "cut my teeth" on trying to configure the COPR to do a Fedora 23 build, since I'm still on Fedora 23.  How would I go about doing that?  As I said I forked the COPR and activated Fedora 23 as an option, would I need to upload my own SRPM based on the git repository, or should I be setting it up to pull automagically from elsewhere?

[1] https://copr.fedorainfracloud.org/groups/g/nodejs-sig/coprs/
[2] https://fedoraproject.org/wiki/Node.js
[3] https://fedoraproject.org/wiki/Packaging:Node.js 
[4] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-lts/build/181534/ 
[5] http://copr-dist-git.fedorainfracloud.org/cgit/@nodejs-sig/nodejs-lts/nodejs.git/



On Wed, Apr 27, 2016 at 8:38 AM Stephen Gallagher <sgallagh@redhat.com> wrote:
On 04/27/2016 04:19 AM, Tom Hughes wrote:
> On 27/04/16 03:00, Stephen Gallagher wrote:
>
>> As for Option 1)? I think someone with more knowledge of the individual modules
>> in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many modules
>> would be broken if we downgraded. If it's sufficiently small, I suppose we could
>> epoch-bump nodejs and its virtual npm Provides: and go that route. I don't love
>> that we will effectively been playing yo-yo with the version in F24, but it
>> would be a solution...
>
> Off the top of my head I'm not aware of anything that requires 5.x and for the
> most part I think people try to support at least 4.x and 5.x at the moment, and
> often earlier versions as well.
>
> Tom
>

OK, I did some repoquery magic just now and came up with (unique-only):


nodejs(engine)
nodejs(engine) >= 0.1
nodejs(engine) >= 0.10
nodejs(engine) >= 0.10.0
nodejs(engine) >= 0.10.12
nodejs(engine) >= 0.10.15
nodejs(engine) >= 0.10.3
nodejs(engine) >= 0.10.36
nodejs(engine) >= 0.1.103
nodejs(engine) >= 0.12.0
nodejs(engine) >= 0.1.90
nodejs(engine) > 0.1.90
nodejs(engine) >= 0.2.0
nodejs(engine) >= 0.2.0-0
nodejs(engine) >= 0.2.4
nodejs(engine) >= 0.2.5
nodejs(engine) >= 0.3.0
nodejs(engine) >= 0.3.1
nodejs(engine) >= 0.3.6
nodejs(engine) >= 0.4
nodejs(engine) >= 0.4.
nodejs(engine) >= 0.4.0
nodejs(engine) >= 0.4.1
nodejs(engine) >= 0.4.2
nodejs(engine) >= 0.4.7
nodejs(engine) >= 0.4.9
nodejs(engine) >= 0.6
nodejs(engine) >= 0.6.0
nodejs(engine) >= 0.6.19
nodejs(engine) >= 0.6.3
nodejs(engine) >= 0.6.6
nodejs(engine) >= 0.8
nodejs(engine) >= 0.8.
nodejs(engine) >= 0.8.0
nodejs(engine) >= 0.8.19
nodejs(engine) >= 0.9.0
nodejs(engine) >= 4
nodejs(engine) >= 4.0.0



So according to this, we have nothing in the package collection that is known to
require only 5.x or later. So that's a point in favor of the 4.x downgrade approach.

I don't love the idea of regressing the versions post-Beta, but it's starting to
look like the least-risky approach. We really have no idea what is going to be
broken by 6.0 and I don't want to stick some poor volunteer with maintaining
backports of a dead upstream release.

_______________________________________________
nodejs mailing list
nodejs@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org