Re: Website "Blog" area
On Sun, Mar 26, 2023 at 4:27 PM Daniel Sahlberg wrote: > CollabNet (now Digial.AI) previously hosted a few sites containing articles > describing design choices and usage examples from Subversion earlier history. > Unfortunately these have been decommissioned and/or neglected and succmbed to > bitrot. > > A preservation effort was undertaken by the PMC with the important help of C. > Michael Pilato and Mark Phippard who arranged for permission to host these > articles within the Subversion website. > > I have edited the articles to match with the standard design of our website > and added them to the staging website: > https://subversion-staging.apache.org/blog/ > > Feedback is of course welcome! Thanks for doing this! I have found only one minor typo which was copied/pasted with the boilerplate text preceding each article. It is fixed in r1908789. Cheers, Nathan
Re: [PROPOSAL] Allow plaintext passwords again.
On Wed, Mar 29, 2023 at 6:02 PM Evgeny Kotkov wrote: > > Nathan Hartman writes: > > > I think a good middle ground is: > > > > * Build with --enable-plaintext-password-storage by default; users who > > want to harden their system can do so, but will need to build their > > own client. > > +1. > > > * Set the default run-time config to store-plaintext-passwords = no > > (if it isn't already; haven't checked) and instruct users on how to > > change it. This makes the decision to store in plaintext an explicit > > one that the user can opt into. (I appreciate that this could be > > changed without the user's knowledge; perhaps the systemwide config > > should always take precedence over the user-controlled one for this > > setting?) > > So, apparently, the current default is "ask". > > I haven't checked all the details, but I think that defaulting to "ask" > already makes the user decision explicit and allows it to happen naturally, > without requiring any additional instructions or knowledge. > > If we change the default to "no", this part of the experience could be worse, > because for the end users it might look like the credentials aren't being > stored for unknown reasons / a bug in the software. Ah, this makes sense. In that case, I'm +1 to leave it as "ask" (no change). Cheers, Nathan
Re: [PROPOSAL] Allow plaintext passwords again.
Nathan Hartman writes: > I think a good middle ground is: > > * Build with --enable-plaintext-password-storage by default; users who > want to harden their system can do so, but will need to build their > own client. +1. > * Set the default run-time config to store-plaintext-passwords = no > (if it isn't already; haven't checked) and instruct users on how to > change it. This makes the decision to store in plaintext an explicit > one that the user can opt into. (I appreciate that this could be > changed without the user's knowledge; perhaps the systemwide config > should always take precedence over the user-controlled one for this > setting?) So, apparently, the current default is "ask". I haven't checked all the details, but I think that defaulting to "ask" already makes the user decision explicit and allows it to happen naturally, without requiring any additional instructions or knowledge. If we change the default to "no", this part of the experience could be worse, because for the end users it might look like the credentials aren't being stored for unknown reasons / a bug in the software. Thanks, Evgeny Kotkov
A Message from the Board to PMC members
Dear Apache Project Management Committee (PMC) members, The Board wants to take just a moment of your time to communicate a few things that seem to have been forgotten by a number of PMC members, across the Foundation, over the past few years. Please note that this is being sent to all projects - yours has not been singled out. The Project Management Committee (PMC) as a whole[1] is tasked with the oversight, health, and sustainability of the project. The PMC members are responsible collectively, and individually, for ensuring that the project operates in a way that is in line with ASF philosophy, and in a way that serves the developers and users of the project. The PMC Chair is not the project leader, in any sense. It is the person who files board reports and makes sure they are delivered on time. It is the secretary for the project, and the project’s ambassador to the Board of Directors. The VP title is given as an artifact of US corporate law, and not because the PMC Chair has any special powers. If you are treating your PMC Chair as the project lead, or granting them any other special powers or privileges, you need to be aware that that’s not the intent of the Chair role. The Chair is a PMC member peer with a few extra duties. Every PMC member has an equal voice in deliberations. Each has one vote. Each has veto power. Every vote weighs the same. It is not only your right, but it is your obligation, to use that vote for the good of the project and its users, not to appease the Chair, your employer, or any other voice in the project. Every PMC member can, and should, nominate new committers, and new PMC members. This is not the sole domain of the PMC Chair. This might be your most important responsibility to the project, as succession planning is the path to sustainability. Every PMC member can, and should, respond when the Board sends email to your private list. You should not wait for the PMC Chair to respond. The Board views the entire PMC as responsible for the project, not just one member. Every PMC member should be subscribed to the private@ mailing list. If you are not, then you are neglecting your duty of oversight. If you no longer wish to be responsible for oversight of the project, you should resign your PMC seat, not merely drop off of the private@ list and ignore it. You can determine which PMC members are not subscribed to your private list by looking at your PMC roster at https://whimsy.apache.org/roster/committee/ Names with an asterisk (*) next to them are not subscribed to the list. We encourage you to take a moment to contact them with this information. Thank you for your attention to these matters, and thank you for keeping our projects healthy. Rich, for The Board of Directors [1] https://apache.org/foundation/how-it-works.html#pmc-members
