Hi Michal! Great to have someone else on board working on a solution here -- and on the infrastructure as a whole.
We always need "someone else" and you should feel very welcome indeed. Indeed, if we can move to a complete solution that does everything needed, that is wonderful, let's indeed work on that together. Thanks a lot, to Chris too -- indeed, if we can work together on a solution that does everything that is currently being done, while also fixing the gaps that there currently are, then let's do that, of course. Gj On Tue, Jul 16, 2019 at 10:39 AM Neil C Smith <neilcsm...@apache.org> wrote: > On Tue, 16 Jul 2019 at 00:36, Michał Dymecki <mic...@dymecki.com> wrote: > > Neil and Antonio commited that not working code into the repository, now > > they want to close the PR that fixes their code, and when Chris wants to > > help with fixing it too, he's being disrespected. Did I miss something? > > Maybe stop throwing git blame around. It's definitely not about > defending a couple of hours work I did on tidying up and modularising > sass files (which incidentally did not fix the *existing* problem > you're pointing out). Or maybe realise that Antonio has spent many, > many hours on this and understands better than you or Chris the full > requirements we have! > > If you want to put time and effort into fixing this, please talk to > people and work on a *complete* proposal that handles the full > requirements around building, content and deployment rather than > tinkering at the edges and making a complex system more complex. So, > yes, the PR *as is* isn't the right approach. That doesn't mean that > a complete JS-based SSG isn't, should you wish to start working on > that, but it has to do *everything* the current framework does. > > > The mentioned projects Apache Tamaya (Incubating) and Apache Incubator > > are not the best examples because they don't even use Sass and there are > > no frontend assets to compile. And Chris is right - with Gradle (or some > > other Java tool) we won't get too far with frontend assets. > > I have (and had) quite a few reservations about JBake, this being one > of them. We can handle a frontend assets pipeline in Gradle if we > really have to. Or we can look to simplify or move stack. > > Of Chris' 4 SSG options, as far as I can tell 3 fail at the first > hurdle (asciidoc), which leaves Hugo - written in Go and potentially > harder for us to extend if we need to. At least with JBake we can > easily extend and have built a relationship with the main developer. > > So, either propose an SSG framework and full migration plan, or help > us work out an easier way for people to work with the existing system > we have. > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
