Hi, On Sun, 7 Oct 2018 at 07:32, Antonio <[email protected]> wrote: > On 10/7/18 12:22 AM, Neil C Smith wrote: > > I was really > > going for the simplest and quickest approach here for immediate needs. > > The idea is to avoid having too many files in the master branch.
OK, I understand what you're getting at. > If each > release delivers about 12k files and we have 10 releases then that would > mean having 120k files in the master branch. That's going burn my SSD. I don't expect us to get there. This is about the simple, manual approach for a couple of releases only. Once we have this automated via the release process then I wouldn't expect us to have *any* Javadoc in the master branch, just the relevant tooling - eg. a Jenkins task to unzip the artefact(s) and push to asf-site. The Javadocs for people to download should be in the mirror system. How about a compromise? Let's pull this and manage it in the asf-site branch directly as and until we have an automated approach ready? > OTOH I understand it's easier for ASF Infra to hold the javadoc on a git > repo, but I don't like that. I'd rather have a directory where the > javadoc is uploaded and then published. Yes, me too! I like the git deployment process in principle, but none of the other things I use here currently involves pushing the build *output* through git. In fact, I'm inclined to have two repositories in that case - one for the build files, one only for pushing deployment artefacts. It would stop the build output swelling the size of the git clone for branches that are not intended to be used locally at all. Best wishes, Neil --------------------------------------------------------------------- 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
