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 >
