On 2/13/17, 12:28 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>Well a lot of what you write sounds sensible … especially with an assumed >Community-Tax (or whatever you call it in the end). > >Eventually it would be an option to have a global “donation service” form >the ASF together with the option to - let’s say add a “Donate to Flex” >button on the projects website in which donations are done to the ASF >with a marker of it being directed to the Flex Project. I wouldn’t want >to have to manage a dedicated bank account and handle all the beurocratic >stuff. I forgot to mention that, besides the community tax, there might be another bill from the ASF for services we use such as email, release distribution storage, and assistance from the financial folks for handling the accounting of the money. The ASF receives bills for the same already, we would just be a micro-version of the same. > >There is a HUGE difference between setting up a Jenkins on the Intranet >and running a Jenkins on the Internet. From the end-user’s perspective, >this isn’t noticeable, but when administrating these system, it is huge. >I had been working on a solution for assisting companies to detect and >fix security vulnerabilities for 4-5 years and have learnt quite a lot on >this. Just some things that would pop my mind: >- You must integrate the authentication into the ASF LDAP (Setting up a >separate one is out of the question) >- You must install the good patches as soon as possible and skip the bad >ones (Usually you have a test-environment to test updates) >- The credentials for accessing the ASF LDAP must be available on the >system (Don’t think Infra would like that) >- To publish artifacts to the ASF Maven repo, credentials of someone must >be provided (alternatively Infra could create technical users, but this >will not happen and I think that’s good that they won’t do that) >- To commit and push to the GIT repos the same applies as for the Maven >repos >- Unfortunately, there is no “setup.exe” to install Security. It’s why a >good system Admin is worth its weight in gold (At least this was one >thing I learnt from my Professor). Every “shortcut” opens dozens of >possible security holes, you have to think about all of them. >- I bet if we were to switch to the “self hosted mode”, I would start >voting -1 setups and decisions to block unsecure shortcuts, we would have >a whole new dimension on discussions here … not looking forward to that. >- If we run our own JIRA/Wiki/Website … we need backups and people >skilled enough to restore them after a catastrophic failure. There are some interesting questions in this regard: 1) If we self-host, would we require someone be a committer first via the usual ways, or would contributing to keeping the VM safe and running be a valid way to earn committer rights? That would require trusting someone to work on the VM before being trusted enough to be a committer. 2) I think any "decentralized" solution would result in Infra wanting to store the backups and maybe dictate how often they take them. > >I guess most things that people are complaining to Infra about are >probably sort of the same type of problems we were having in the past. >The thing is that we wanted them to provide a build that fits the build >we created. What I did, was to simplify the build and create a common >ground with Infra towards what’s possible and what’s not and to adjust >the build accordingly. If all projects would use this type of dialog I >guess, we wouldn’t have this type of problems. Well, having a "what's not possible" list is bad for the project if we need to do some of those things on that list. This is why a decentralized solution is better for the project. But there was a recent thread where a Mac CI Server was taken down because there weren't customers for it for a period of time but someone did need it. Again, I don't like these decisions taken out of our hands. If we need to test on some stinky old version of Java, we should be able to acquire the resources and do it and not have Infra say they are too busy or don't have the resources. -Alex
