> > 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? 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
