Made a request to maintain sys-kernel/ck-sources as per #569262.
commit dcf3748ee9de042cbcff9524e1e064e7b71bfa35 Author: Göktürk Yüksek <gokturk@gentoo.org> Date: Thu Jan 19 23:29:14 2017 -0500 sys-kernel/ck-sources: add maintainers #585552 #606562 Package-Manager: portage-2.3.0
personal (non-FOSS/Libre) priorities which I need to focus on for a while. (updated URL accordingly)
(In reply to kuzetsa from comment #2) > personal (non-FOSS/Libre) priorities which I need to focus on for a while. > Any ETA for your return?
(In reply to Göktürk Yüksek from comment #3) > (In reply to kuzetsa from comment #2) > > personal (non-FOSS/Libre) priorities which I need to focus on for a while. > > > > Any ETA for your return? This confusion was my fault. Apology. (I was carelessly vague) Related to some personal affairs which were originally expected earlier this year, but got delayed until now. Travel and commuting is involved, etc. Start date will be some time 1st quarter 2018, January at the earliest. Months ago, I tried to communicate and warn a few gentoo people (in private) that joining on as a developer might not be right until I knew for certain what my availability would be: Without going into specific personal details, health-related concerns were expected to be the greatest limiting factor, and that's still a concern. This is why the maintainer bug needed an update. I will need to be even more careful now to not strain myself and "crash / burn out"; when the choice is between looking after my health, or tending to a bump / refactor / bugfix, I'll need to catch up on rest. (more sustainable and responsible than "pushing through") [in]conveniently, upstream kernel.org releases are very frequent, but also more predictable and steadier than most upstreams - this makes it easier to estimate the impact on my contributions: The risk that I'll miss a timely CVE-related release is increased, and I may end up skipping one or two kernel minor bumps per month during 1st/2nd quarter 2018. Major bumps shouldn't be delayed significantly, likely within a week (or so) after availability of an upstream ck patchset releases, but could still zero-day if I'm not busy (and/or resting). Summary: Intermittent scheduling-related decrease to my availability during a portion of 1st/2nd quarter 2018 "Returning" from a schedule change isn't the right wording - this is a priority shift. Leaving the original update at a more concise: "priority shift" would've been better, rather than the URL which I (confusingly) selected to summarize. Again, sorry for the hasty [mis]communication. I was frustrated about something unpleasant, and didn't have the patience left to communicate more clearly.
Dear proxied maintainer, This note is sent to you as part of mass notification to all proxied maintainers whose maintainer bugs do not seem to list their real name. If you have provided your real name on the commits nevertheless, please disregard it (there's no need to update your bug either). Please note that according to our new copyright policy, all contributions require GCO [1] sign-off using *your real legal name*. The record of this sign-off will have to be stored publicly in the commit messages. We are required to reject anonymous or obviously pseudonymous contributions. If you have been doing that so far, please look into the possibility of using your real name in contributions. If you can't do that, I'm afraid you won't be able to proxy-maintain packages in Gentoo anymore. If that is the case, please let us know to remove you from the metadata. TIA, Michał Górny [1] https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin
The law in my jurisdiction affirms the common law right to use my name, but explicitly requires using the name consistently. Refusing to waive this right is my perogative. informally, people all me kuza (kuzetsa is the formal version)
I'm sorry but given the fact that you're continually refusing the follow the rules and the amount of hassle you're caused so far greatly exceeds the benefit from bumping a trivial kernel package, I don't think we're going to continue accepting you as a proxied maintainer. Thank you for all the work so far and good luck with your future endeavors.
(In reply to Michał Górny from comment #7) > I'm sorry but given the fact that you're continually refusing the follow the > rules and the amount of hassle you're caused so far greatly exceeds the > benefit from bumping a trivial kernel package, I don't think we're going to > continue accepting you as a proxied maintainer. Thank you for all the work > so far and good luck with your future endeavors. Quote From: Legally Binding Electronic Documents: Digital Signatures and Authentication - Christopher Reed (in "The International Lawyer", spring 2001) In the context of Internet communications, the thing to be signed, an electronic document, exists more as a matter of metaphysics than as a physical object. For this reason, it is very difficult for an electronic signature method to meet any physical requirement ofform. For example, some of the English cases and statutes on physical world signatures appear to state that a signature must take the form of a mark on a document. A mark, in relation to a hard copy document, has the characteristics of visibility and physical alteration of the thing that is marked. None of the ways in which an electronic document communicated via the Internet may be signed are capable of producing documents that exhibit these characteristics. A distinction must be made between the information content of a document and the carrier of that information... Specific With a footnote / citation: Morton v. Copeland [1855] 16 CB 517, 535 (Maule J) signing "does not necessarily mean writing a person's Christian and surname, but any mark which identifies it as the act of the party"
My interpretation of the closed maintainer bug is that I did not follow the correct route for redress, please explain what I can do to remedy the situation: This means I probably misunderstood the comments (github) about the maintainer bug not matching the metadata.xml change in the PR, and/or a request for explanation was - it seems like it may have been "lip service", and an explanation for the PR was insufficient - either way, I'd like a way forward, because there has to be a better remedy than closing the maintainer bug.
(In reply to kuzetsa CatSwarm (kuza for short) from comment #9) > My interpretation of the closed maintainer bug is that I did not follow the > correct route for redress, please explain what I can do to remedy the > situation: > > This means I probably misunderstood the comments (github) about the > maintainer bug not matching the metadata.xml change in the PR, and/or a > request for explanation was - it seems like it may have been "lip service", > and an explanation for the PR was insufficient - either way, I'd like a way > forward, because there has to be a better remedy than closing the maintainer > bug. reopened pending GLEP-76 / council vote being on the record with regards to the intent to be inclusive of refugees, those who are plural, trans, nonbinary, intersex, refugees, from different culture with different naming conventions, etc.
Created attachment 849207 [details, diff] adjustment proposal for GLEP-76 seeing as council still hasn't voted. https://archives.gentoo.org/gentoo-project/message/ef20321c60472ac4c91653236fb8a346
(In reply to kuzetsa CatSwarm (kuza for short) from comment #11) > Created attachment 849207 [details, diff] [details, diff] > adjustment proposal for GLEP-76 > > seeing as council still hasn't voted. > > https://archives.gentoo.org/gentoo-project/message/ > ef20321c60472ac4c91653236fb8a346 This seems to be the wrong bug?
