PS: Just for the record, Oracle doesn't relicense anything at all to
Apache. Instead, Oracle donates code to Apache, and we together, here in
Apache NetBeans community, do the relicensing.

Gj

On Wed, Jul 25, 2018 at 2:17 PM, Geertjan Wielenga <
[email protected]> wrote:

>
>
> On Wed, Jul 25, 2018 at 11:13 AM, Tim Boudreau <[email protected]>
> wrote:
>
>> >
>> > Resurrecting this thread, since Tim Boudreau recently Mavenized the
>> > contrib repo:
>> >
>> > https://github.com/timboudreau/netbeans-contrib
>>
>>
>> I sent a note to this list about that on Monday, but got no response at
>> all.  Wondering if it went into a black hole, or nobody cares :-)
>>
>>
>> > The Mavenization is certainly welcome (to me at least!) but someone
>> > needs to officially decide what to *do* with all that stuff.
>>
>>
>> Agreed.  I hadn't seen any specific proposal, so I figured I'd do
>> *something* since contrib/ still contains things I rely on daily.
>>
>> So here's a proposal:
>>
>> 1.  The *big, critical thing that needs to happen* is for Oracle to
>> relicense this code to Apache license, the same as NetBeans.  Everything
>> in
>> there was contributed under a contributor agreement that assigns joint
>> copyright ownership to Oracle nee Sun.  So, Oracle is the one party that
>> can do that for everything - former Oracle employees can't even relicense
>> their own code, since it was work-for-hire and only external contributors
>> hold joint copyright.  Geertjan, can you make that happen?
>>
>
>
> Yes, there's no question or discussion about this at all. It will happen.
>
> We maybe should bump this up before the current plan for the 4th donation,
> which is focused on C/C++. I think we should prioritize 'contrib' over that.
>
> Gj
>
>
>
>
>>
>> 2.  I agree with Jesse that the things that are actively maintained there
>> should probably find separate homes on Github or wherever their
>> maintainers
>> want.  In the meantime, I'm happy to babysit the repo while that happens
>> (likely it can't happen until 1. is done).
>>
>> So what I'd suggest is that Geertjan (or whatever Oracle employee is
>> empowered to do it) fork the repo, change the license headers (scriptable,
>> not hard), and - depending on who wants it long-term - either send me a
>> pull request, or if the Apache organization wants to own it going forward,
>> I can retire this repo.
>>
>> 3.  In the meantime, if anyone has stuff they want to work on in there,
>> I'm
>> happy to add anybody who wants as a collaborator or accept pull requests,
>> or whatever works for folks - until the licensing is straightened out and
>> things can find their own homes, it's probably best for there to be one
>> repository of record.
>>
>> 4.  Distributing things:  I have a temporary plan for this:  Set up a
>> continuous build of the whole enchilada on my Jenkins server, and dump all
>> the modules of a separate instance of
>> https://github.com/timboudreau/meta-update-center - all the build has to
>> do
>> is dump the contents into a folder it's watching, and updates will show
>> up.  It's a tiny, lightweight update center server - example here
>> https://timboudreau.com/modules - no user rankings or frilly UI (could be
>> added if someone were ambitious), but it does what it does with zero
>> headaches.
>>
>> I'll probably get to that next week - I'm replacing my server on Friday
>> with a 72Gb box, so since I've migrated all of the VMs, I'm not making
>> major changes on the old machine this week as I'd have to replicate them.
>>
>> 5.  Longer term...
>>
>> A. There should probably a continuous build of this stuff somewhere else
>> (Apache? Something else?), which interested module owners can add jobs to,
>> with the same sort of automated distribution (Jenkins publishes nbms,
>> meta-update-center polls the URL of the built NBM and automatically
>> updates
>> if the Last-Modified header has changed) - so there remains some kind of
>> one-stop-shopping for community modules.  I was never a huge fan of the
>> plugin portal's model for how *developers* use it, since you had to go and
>> manually update it - that's actually what inspired me to write
>> meta-update-center.  So you set up Jenkins to build a "stable" branch, and
>> that gets distributed automagically whenever you push to it.
>>
>> B.  Need a way to flag stuff in contrib as clearly junk, because some of
>> it
>> is.  We could just nuke stuff, or remove it from the master POM, but at
>> the
>> moment that's also serving as the notes for what needs fixing, so I'm not
>> dying to mix concerns there, and probably shouldn't take a chainsaw to
>> stuff until the relicensing is done or that will complicate things.
>>
>> C. Something fancier could and probably should be done for distribution
>> long-term.  I can contribute hosting of some stuff for now, but I barter
>> hosting a local TV station's streaming video server on that box for free
>> commercial-grade bandwidth, and I've had situations where Comcast techs
>> came in and screwed with the network configuration and I had to go figure
>> out what they'd done and fix it.  So we're talking 95% uptime, but not
>> five
>> nines.  It will do for getting things going, though.
>>
>> Thoughts?
>>
>> -Tim
>>
>>
>> > Probably
>> > all the live modules or logical module groups (those active on the
>> > Plugin Portal) should each get their own GH repo somewhere—does not
>> > make sense to shove them all into one repo. And then how do bits get
>> > distributed to users? I am not sure what happened to deadlock and its
>> > CI job for contrib modules. Plugin Portal still seems to be alive but
>> > what is its future? Of
>> >
>> > http://plugins.netbeans.org/my-plugins
>> >
>> > there are a number of plugins I would like to keep running and
>> > available; some were already being maintained on GitHub, but some
>> > (notably quickfilechooser) were not.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [email protected]
>> > For additional commands, e-mail: [email protected]
>> >
>> > For further information about the NetBeans mailing lists, visit:
>> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>> >
>> >
>> >
>> >
>>
>> --
>> http://timboudreau.com
>>
>
>

Reply via email to