I think C++ is much more important. --emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 25 July 2018 3: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 --------------------------------------------------------------------- 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
