Re: [gentoo-dev] Signed-off-by verification incoming
On 09/29/2018 10:52 AM, Thomas Deutschmann wrote: > On 2018-09-29 15:14, Jeroen Roovers wrote: >> Please: >> >> 0a) Explain to me how to fix my commits that I now can't push, or > > Like you have already figured out, "git commit --signoff" when doing > profile/eclass changes and to fix things, "git commit --amend --signoff". > > >> 1) Update repoman to enforce it _before_ the commit is executed. > > Please add > >> DCO_SIGNED_OFF_BY="Larry the Cow " > > to your make.conf and "repoman commit" will do it for your. > > >> 2) Wait for the repoman update to trickle down to all developers. > > DCO_SIGNED_OFF_BY is present since 2013-04-22 20:01:29 -0700. So it > should be available for all developers. > > >> 3) Announce it ahead of time. > > I agree. Communication was bad. We should have included dev howto with > that announcement. > > this thread was mentioned today in #gentoo-dev-help [20:35:26] I never would've thought to look for repoman docs there O__o [20:36:16] ironically, the documentation for this repoman feature is in the manpage for make.conf instead of the manpage for repoman - weird, but I guess it is technically documented already sneaky :) maybe could be in the repoman manpage instead? (too?)
Re: [gentoo-dev] Signed-off-by verification incoming
On 09/29/2018 09:29 AM, Rich Freeman wrote: > On Sat, Sep 29, 2018 at 9:25 AM Dirkjan Ochtman wrote: >> >> Some kind of repoman support would make this much easier to handle. As >> it is, doing this by hand for the trivial case (only my own changes) >> is a PITA. repoman could grow some kind of --sign-off option that >> appends this to the commit message presumably? >> > > Does "repoman commit" no longer do the right thing? > amd64 keyword-stable app-portage/repoman doesn't seem to, so I had to use repoman manifest && git commit -s -S recently
Re: [gentoo-dev] Help with category for Authenticator
On 08/28/2018 10:32 AM, Alexander Trotsenko wrote:
> Hello, guys!
>
> I tried asking this question in #gentoo-proxy-maint IRC and I was told I
> should venture for gentoo-dev mailing list.
>
> So I introduced a new package into Gentoo, Authenticator
> (https://github.com/bilelmoussaoui/Authenticator). I placed it under
> gnome-extra. However, shortly after the commit, gnome-extra guy said it
> does not belong there [...]
> I currently consider to move it to app-crypt. Some folks also suggested
> net-misc as a reasonable destination. [...]
>
> Thank you!
> Alex.
>
>
gnome-extra is for things maintained by gnome, right?
app-crypt is more accurate than net-${anything}
--kuza
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 07/10/2018 09:44 AM, Rich Freeman wrote:
> On Tue, Jul 10, 2018 at 9:38 AM kuzetsa wrote:
>>
>> I think authorship is a good point / distinction, Mart.
>>
>> Authorship was never shown in dev-timeline for addresses
>> which aren't @gentoo.org anyway. That's a separate issue,
>> so this policy change shouldn't affect proxy-maint?
>>
>
> Might I suggest bringing authorship issues into a separate thread? It
> really seems like a completely separate issue. IMO devs who are
> authors but not committers should probably also use their @g.o
> addresses, though it is a little less critical there. We're talking
> about the committer here, and the committer will always be a Gentoo
> dev for these repos, and I don't see any reason that we shouldn't have
> a matching email address between that and LDAP. The alternative would
> be to have some other key, and that just seems overly complex.
>
Authorship was brought up by: [ Mart Raudsepp ]
It's germane, and wanting clarity doesn't hurt:
... as quoted here:
On 07/09/2018 06:29 AM, Mart Raudsepp wrote:
> As long as that doesn't imply authorship, which seems to be as planned
> (for committer field only, as you said). Hopefully it's easy for people
> to set it up so that it uses gentoo address for committer and something
> else for author, albeit I don't see any config for it, but should be
> able to at least go via a script that uses the appropriate env vars.
~{prune}~
> Mart
>
^ As I think Mart may have been asking:
(or maybe just a related concern)
To avoid mistakes and confusion, it should be stated
unambiguously if //only// the commit field should be
modified (if not already a @gentoo.org address), and
the author field (in particular, commits authored by
persons not in LDAP / without @gentoo.org addresses)
ought to be left as-is, or if the intent is to imply
that both fields need to be @gentoo.org address.
Stating clearly that the author field should be left
as-is (if it's set to a n...@gentoo.org address) is
probably enough here.
I think the confusion may have partly been the
subject line for this thread, vaguely worded:
["... use their @gentoo.org address ..."],
which may accidentally imply that committers need to
apply @gentoo.org in all fields, not just committer.
the word "only" was in a few places, but if skimming
the thread it may not have been obvious. ::shrug::
Also, I agree:
dev-timeline tool not recognizing authorship ought to
be an issue for a separate thread, as this one seems
to be about the metadata in the commits themselves.
--kuza
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 07/09/2018 06:29 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 09.07.2018 kell 10:40, kirjutas Michał Górny:
>> Hi,
>>
>> We currently don't enforce any particular standard for e-mail
>> addresses
>> for developers committing to gentoo.git. FWICS, the majority of
>> developers is using their @gentoo.org e-mail addresses. However, a
~{prune}~
>> Is anyone opposed to that? Does anyone know of a valid reason to use
>> n...@gentoo.org address when committing?
> As long as that doesn't imply authorship, which seems to be as planned
> (for committer field only, as you said). Hopefully it's easy for people
> to set it up so that it uses gentoo address for committer and something
> else for author, albeit I don't see any config for it, but should be
> able to at least go via a script that uses the appropriate env vars.
~{prune}~
> The only issue I see is that of slight complications on handling the
> different addresses for author and commit, that's all that comes to
> mind.
>
>
> Mart
>
I think authorship is a good point / distinction, Mart.
Authorship was never shown in dev-timeline for addresses
which aren't @gentoo.org anyway. That's a separate issue,
so this policy change shouldn't affect proxy-maint?
(There are a few authors who are proxy-maintaining)
--kuza
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/26/2018 09:26 PM, Rich Freeman wrote: > On Mon, Mar 26, 2018 at 9:19 PM, kuzetsa wrote: >> On 03/20/2018 08:08 PM, Rich Freeman wrote: >> >>> >>> Actually, I think it is more of a technical constraint. It is >>> basically impossible to blacklist somebody on a mailing list, since >>> all they need to do is roll up a new email address. >>> >>> I can think of various arguments for whitelisting or not whitelisting, >>> but it seems silly to blacklist. >>> >> >> require active stewardship (moderation, blacklisting, etc.) >> >> entry barriers to participation (default deny / require whitelist) >> >> if there are limitations on free speech, someone has to bear the burden. >> for gentoo to have list moderation (blacklist approach) which isn't >> dysfunctional, the main barrier to resources will be the human resources >> end of things, not technical constraints. The tools themselves are easy >> enough to use, but people who are willing and able to use them, and with >> a clear guideline for how it needs done is a comrel issue which the >> foundation needs to sort out. >> > > List moderation isn't the same as blacklisting. With moderation > you're effectively whitelisting because the first post anybody makes > would be held for moderation, and depending on the approach you could > moderate everything. > > If you allowed new subscribers to post without being held for > moderation, then the issues I spoke of would still apply, no matter > how much manpower you threw at it. > I think this may be a misunderstanding? no? there might be some mailing list jargon term: "moderation" which I was unaware of: I was more referring to how IRC chatrooms have an op, forums have moderators which DO NOT screen individual posts, etc. I think I know of the other version, and it might be analogous to the mechanism you meant? for example: websites which hold back all comments which are posted anonymously (non-trusted users) until a moderator can approve it. I've never used mailing list software which has that feature (I think that may be what you're referring to) - I mostly meant someone (or a team) with the specific duty to hold people accountable for their posts (since the list is public-facing, this should include @gentoo.org devs too because it sets a weird precedent to have disparate enforcement) specifically - I was referring to persons (staff) who are moderators. (active stewardship to check for problems which need addressed) I think the mechanism you describes sounds like some sort of greylist / tiered version of default deny or something like that. Interesting. the "require whitelist / default deny" version of having a closed list seems the same - expecting users to contact a dev to relay messages, or go through the dubiously [un]documented process of getting whitelisted. unless that process has a standardized format, it seems worse than the greylist because individual developers have the autonomy to [not] sponsor people for whitelist, or approve posting on a user's behalf. the lack of transparency for the process is a concern, I mean.
Re: [gentoo-dev] Mailing list moderation and community openness
On 03/20/2018 08:08 PM, Rich Freeman wrote: > On Tue, Mar 20, 2018 at 7:54 PM, Benda Xu wrote: >> William Hubbs writes: >> >>> I do feel that this decision reflects badly on us as a community and >>> should be reversed immediately. The proper way to deal with people who >>> have bad behavior is to deal with them individually and not put a >>> restriction on the community that is not necessary. >> >> I agree with William. Dealing with individuals makes more sense. >> >> It boils down to an attitude of assuming outsiders are good (blacklist >> to ML) or bad (whitelist to ML) by default. > > Actually, I think it is more of a technical constraint. It is > basically impossible to blacklist somebody on a mailing list, since > all they need to do is roll up a new email address. > > I can think of various arguments for whitelisting or not whitelisting, > but it seems silly to blacklist. > require active stewardship (moderation, blacklisting, etc.) entry barriers to participation (default deny / require whitelist) if there are limitations on free speech, someone has to bear the burden. for gentoo to have list moderation (blacklist approach) which isn't dysfunctional, the main barrier to resources will be the human resources end of things, not technical constraints. The tools themselves are easy enough to use, but people who are willing and able to use them, and with a clear guideline for how it needs done is a comrel issue which the foundation needs to sort out.
Re: [gentoo-dev] Integrating Portage with other package managers
On 03/07/2018 11:06 AM, anote...@teknik.io wrote: > It seems reasonable to me to 'hook' portage into these > other package managers, so that running 'emerge bar' > would actually run 'cabal install bar' rather than > downloading sources and running 'ghc'. it gets tricky when there's no good way to even fetch the source, I mean. Sorry about not proofreading: On 03/08/2018 09:47 AM, kuzetsa wrote: > dependencies which can't otherwise be satisfied is the > point of the original poster / creator of this thread: I'm certain I worded that wrong. My intent had been to say that a point which //was not addressed by// the OP (oops) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Integrating Portage with other package managers
On 03/08/2018 07:25 AM, Michael Orlitzky wrote: > On 03/08/2018 12:54 AM, Benda Xu wrote: >> >> This title itself is amusing enough >> >> Motherfuckers need package management >> > > Which if it is not clear, is intended to be funny. > > the colorful language was proportional to the enthusiasm. decent info, even though the excited person who wrote it made me roll my eyes (I clicked for the info ::shrug::) as per this thread: NuGET (mentioned in the article) is something I had briefly considered trying to hook into: an upstream decided that one of their own libraries (it was written / maintained by upstream) should be unbundled rather than vendored, but instead of giving it standalone packaging, they decided to make it only available via NuGET. Since I had never used .NET before, I had no idea what that even was, initially. It was a "an experience". dependencies which can't otherwise be satisfied is the point of the original poster / creator of this thread: On 03/07/2018 11:06 AM, anote...@teknik.io wrote: > Is this a feature/improvement other Gentoo users/developers > would be interested in? If so, I would love to help discuss > and potentially help with its implementation. > The problem with something like NuGET, is that I don't know how to safely support the package manager itself. I think it's a terrible idea to let "something like that" loose on a gentoo system... https://docs.microsoft.com/en-us/visualstudio/mac/nuget-walkthrough ^ I guess they officially support mac, but still. what happens when the developer of a package manager decide they need root access to your system, but then do things "their way"? I've got some concerns. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs: games-engines/love
From freenode / #gentoo-proxy-maint [09:13:53] do I need to reply to the gentoo-dev ML to be able to proxy-maintain games-engines/love or can I just fire off the github PR with commits for EAPI 6, version bump, etc. (it's not up to date & being dropped by current maintainer) Resolution: It was decided that a ML post would be proper / polite. I'd like to take over this package, and will make some commits in the next week or so (not sure how much will be involved to do the required things mentioned above) -- kuza On 02/01/2018 05:36 AM, Chí-Thanh Christopher Nguyễn wrote: > Hi all! > > Due to lack of time, I have to drop maintainership of games-engines/love. > There is some user interest in this package, and a version bump is > needed (bug 640802). > > > Best regards, > Chí-Thanh Christopher Nguyễn > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 01/10/2018 09:55 AM, Alexander Berntsen wrote: > On 10/01/18 08:55, Lars Wendler wrote: >> Seems we're turning into an elitist club or something... > Gentoo has already had the reputation of being an elitist club for > years. As such I'd like to see steps to remedy this status, rather than > taking steps like this, which just exacerbates the unfortunate status. Definitions matter: An impressive skillset could be called elite. One form could be an elected set of people who have veto power for decisions about the gentoo project. Another definition could focus on social standing, influence, the ability to control peers and apply pressure to defend one's status. This is not often welcoming to outsiders with differing viewpoints. Many aspects of gentoo development can be called elite. The 3rd definition is the one which I'm least comfortable with. Elaboration follows: If the merits of organizational and technical goals are the only definitions used, there is no reason for the elitism to be feared. Competency is not a problem. Perhaps this is a discussion more suited to the gentoo-project mailing list. It's taking a turn away from development concerns again. That's part of the point for this new posting restriction. On-topic subject matter can be relayed, and/or persons prone to development concerns are still able to be whitelisted. I see no problem here. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 01/09/2018 08:21 AM, Aaron Bauman wrote: > > On January 8, 2018 9:39:47 PM EST, Benda Xu wrote: >> Hi kuzetsa, >> >> kuzetsa writes: >> >>> The term "beyond" feels wrong & confusing. >>> (Not sure what to replace it with though) >> How about this? >> >> default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ >> default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+ >> default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ >> >> Yours, >> Benda > I like this as it is shorter and makes the version ranges more clear. Lgtm. > > -Aaron Yes. Using a plus looks nicer / cleaner to me too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
On 01/10/2018 05:57 AM, David Seifert wrote: > On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote: >> On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote: >> >>> On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote: * Posting to the list will only be possible to Gentoo developers and whitelisted additional participants. >>> This is so contrary to what I and I thought Gentoo stands for: >>> openness, transparency, inclusiveness even when these require a >>> rather >>> thick skin and result in high noise. It's a price worth paying. >>> >>> I guess I should a) pay more attention to council elections b) >>> consider >>> the idea that the whole council thing as it stands now is just not >>> working. >>> >> Wow. I couldn't have said it better. >> Seems we're turning into an elitist club or something... >> I wonder how many users we're going to loose on this one. Well done >> council :-( >> > If your only reason to use Gentoo is because you can post to the main > developer ML, and not because we try to provide a great distribution > with lots of choice, a current toolchain and lots of customization, > then you're likely using the wrong distribution. > If development of a quality distribution which meets these goals requires thick skin, something is broken: I've never seen anything from the gentoo foundation which suggests that the gentoo developer mail list should be considered a safe space for disparaging remarks. Think of the messaging on this - for every 1 or 2 people who are willing to come forward to address these concerns, there are likely "not zero" who didn't want to deal with confrontation and the risk that rudeness and hostile behavior would be defended. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.
On 01/08/2018 01:38 AM, Benda Xu wrote: > Hi, > > I would like to introduce some 17.0 profile for Prefix. It also > introduces separate profiles to support different ranges of linux > kernels. > > | name | linux| glibc | > |--+--+---| > | beyond-kernel-2.6.16 | [2.6.16, 2.6.32) | <2.20 | > | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 | > | beyond-kernel-3.2| [3.2, latest)| latest| > > Attached is the patch. Thoughts and comments? > > Yours, > Benda > --- > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi | 1 + > .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++ [...] Not sure what else is changed / added. The term "beyond" feels wrong & confusing. (Not sure what to replace it with though) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deleting old news items
On 01/06/2018 05:05 AM, Ulrich Mueller wrote: >> On Sat, 6 Jan 2018, Duncan wrote: >> $ equery b news.eselect >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) >> So in that case it's not the PM, but eselect. > In fact, it is the PM that would do the filtering, before filling the > list of unread news items in /var/lib/gentoo/news/news-gentoo.read. > > Filtering in eselect news would be problematic: Obtaining the list > of items with "eselect news list" and e.g. reading them with "eselect > news read" are issued as separate commands, which requires that the > list of valid items does not change. However, time-based filtering > could cause a race condition, like an item expiring between execution > of the two commands. > > Ulrich The race condition could be addressed by issuing a warning at or around the time when expirations occur (midnight), with or without detecting specific expirations which may have occurred: WARNING: [n] is about to / has expired, and the list order is about to / has just changed (as appropriate for list and read respectively) Otherwise just warn when the commands run near midnight. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/03/2018 06:07 AM, Ulrich Mueller wrote: >> On Tue, 2 Jan 2018, Alec Warner wrote: >> Problem: >> New stages have numerous news items listed that are likely not >> relevant, but are shown due to limitations in the filtering in NEWS >> items. E.g. on a recent stage3: >> [...] > We could add an "Expires:" header to the news item format, and the > package manager (or eselect news) could mask old items based on it. > > Ulrich the storage footprint for news entries is cheap. why not just improve the user-facing documentation: if someone wants to hide "old" news, they opt-out. It's much harder to opt-in to viewing deleted news. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deleting old news items
On 01/03/2018 05:53 AM, Michał Górny wrote: > W dniu wto, 02.01.2018 o godzinie 19∶13 -0500, użytkownik Alec Warner > napisał: >> Problem: >> >> New stages have numerous news items listed that are likely not relevant, >> but are shown due to limitations in the filtering in NEWS items. E.g. on a >> recent stage3: >> >> nspawntest / # eselect news list >> News items: >> [1] N 2013-09-27 Separate /usr on Linux requires initramfs >> [2] N 2014-06-15 GCC 4.8.3 defaults to -fstack-protector >> [3] N 2014-10-26 GCC 4.7 Introduced the New C++11 ABI >> [4] N 2015-02-02 New portage plug-in sync system >> [5] N 2015-07-25 Python 3.4 enabled by default >> [6] N 2015-08-13 OpenSSH 7.0 disables ssh-dss keys by default >> [7] N 2015-10-22 GCC 5 Defaults to the New C++11 ABI >> [8] N 2016-06-19 L10N USE_EXPAND variable replacing LINGUAS >> [9] N 2017-11-30 New 17.0 profiles in the Gentoo repository >> >> Many of these are always displayed. For example: >> >> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt >> >> has "Display-If-Installed: sys-apps/portage" and will be displayed on >> nearly every Gentoo machine. While relevant in 2015; I'm skeptical that its >> relevant today. I am also considering explicit changes in the filtering >> directives to resolve this in the future. >> >> Glep42 states: >> >> --- >> News Item Removal >> >> News items can be removed (by removing the news file from the main tree) >> when they are no longer relevant, if they are made obsolete by a future >> news item or after a long period of time. This is the same as the method >> used for updates entries. >> --- >> >> I suggest we delete all entries prior to 2016. Git keeps history forever, >> so folks can gander at the old entries on gitweb.gentoo.org: >> > For completeness, I should point out that I've seen one user complaining > about old news items disappearing. While I support the motion, I think > we should take some care to make sure that there is some 'replacement' > documentation for the things announced by news items. > > In other words, it's a bad idea to remove news items when the available > documentation explains the 'before' state and the news item is the only > source of information of the 'after' state. > I've personally needed to refer back to a few of those news entries more than once. In particular, the instructions for 17.0 profile migration, the entry about -fstack-protector, C++11 ABI notices, and the portage sync plugin system. The most recent time I needed some of that was this week. Following a mix-up with crossdev (still documenting the bug) I decided to repair my toolchain in-place using a stage3 tarball rather than a full OS reinstall. Specifically, the info was handy because there isn't much documentation on how to correctly bootstrap from anything less than a valid / non-broke stage3 tarball. Even if nobody else has weird issues and needs to use a strange method to repair their system in-place, the 17.0 profile migration news entry is recent enough that it should be retained for at least a FULL YEAR, I feel. - kuza signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org
On 12/20/2017 06:17 PM, Nils Freydank wrote: > Am Mittwoch, 20. Dezember 2017, 17:48:54 CET schrieb kuzetsa: >> On 12/16/2017 10:14 AM, Nils Freydank wrote: >>> Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa: >>>> On 12/05/2017 05:18 PM, Nils Freydank wrote: >>>>> 5. Reasons for warnings and bans >>>>> >>>> --snip-- >>>> --- other snip --- >>> Could you write a short paragraph for this? >> Haven't been paying much attention to this thread. >> (I was quoted here - Point #c versus #d) >> >> Am I being asked to write something up? > Yes, exactly that is what I’m asking for. I think your point c vs. d > statement > was that good it might be best if you’d write two or three sentences. This language should fit heading #5 [ Reasons for warnings and bans ] -- Posts to the list should be done in good faith. If posts are clearly germane (limited to the topic under discussion) this should prevent most personal disputes from being rehashed. -- The term germane is less subjective than "on topic", but including a brief definition can be helpful as not all people on the list will know the word; it's not a super common word in english (except for parliament / congress). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org
On 12/16/2017 10:14 AM, Nils Freydank wrote: > Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa: >> On 12/05/2017 05:18 PM, Nils Freydank wrote: >>> 5. Reasons for warnings and bans >>> >> --snip-- >> >>> c) spamming, i.e. flooding discussions with lots of messages in a row >>> d) constant postings off topic, i.e. disrupting discussions with unrelated >>> questions >>> >>> (constant means more than two times in a row) >> Point #c versus #d >> >> #c - there can (and often are) good faith reasons for >> multiple postings "in a row", such as when responding >> to multiple threads, and/or to multiple posters within >> the same thread. Even just people who are awake (and >> would respond) at a time when other participants in the >> list would be sleeping could complicate this rule. > Valid point. > >> #d - definition for constant seems unnecessary. For an >> alternative, maybe refine the definition to either >> use a 72 hour window or similar, or even just a basic >> expectation for discussion to be germane (on-topic) >> with refusal to stay on-topic (when warned) being the >> measure. Perhaps three strikes (per day?) are when >> the enforcement could start. parliament / congress >> and other formal assemblies have models for this. > Sounds good to me. As spamming is *always* off topic > this should even catch point c). > > Could you write a short paragraph for this? Haven't been paying much attention to this thread. (I was quoted here - Point #c versus #d) Am I being asked to write something up? Clarification would be appreciated. - kuzetsa signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
Neat. I didn't spot those new fbreader feature(s). I also didn't notice m-n status on fbreader deps. I'll review this thread, research upstream(s), etc. (if it's within my abilities & available time, I'll maint) - kuzetsa P.S. yes: at times, QA messages are a tad vague On 12/14/2017 07:56 AM, gro...@gentoo.org wrote: > This is in fact a newer version of liblinebreak (under a new name). > liblinebreak is m-n. The ebuild is just a slightly improved > liblinebreak-2.1. > This new version improves the functionality of fbreader (the new > revision -r4 depends on libunibreak). Removing libunibreak would > require also removing the improved fbreader-0.99.4-r4. libunibreak > allows fbreader to correctly hyphenate words in languages other than > English (I am now reading a Russian book in this new revision of > fbreader, and it is substantially better than doing the same in the > previous version). I am definitely against removing libunibreak and > fbreader-0.99.4-r4, and returning to the old > no-hyphenation-in-non-English-books behaviour. > > Andrey > signature.asc Description: OpenPGP digital signature
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
On 12/10/2017 03:21 AM, Michał Górny wrote: > Your attack on me is fully unfounded and completely inappropriate. FYI, > just let me correct a few facts here: --- pruned --- > 3. The agenda item wasn't expressing 'feelings of one developer', as you > know it. It was written by me because I found the time to prepare > a rationale of *facts* to support it. Don't shoot the messenger. Yes. I'm a fan of transparency, but there are many people with passionate views, so sometimes it's harder to have a calm discussion about social matters. If / when these discussions happen, remarks about various actions by specific people tends to escalate hostility. On the other hand, generalizations about how gentoo-related communication should occur isn't a "shots fired" or "touchy subject" situation. TL;DR - Public fighting doesn't help gentoo. -kuzetsa P.S. I'm trying to stay out of these contentious topics. Also, your composure / tone seems fine to me, mgorny. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/05/2017 06:12 PM, Rich Freeman wrote: > On Tue, Dec 5, 2017 at 5:41 PM, Kristian Fiskerstrand wrote: >> >> We do not, but that presumes actual abuse has been demonstrated. >> "spamming the mailing list", where the posts are regarding Gentoo, isn't >> automatically abuse because some people are uncomfortable about the >> information being presented, or they disagree with it. >> > I don't have any issue with discussion of facts, or even the offering > of opinion, but the problem is that in these sorts of situations one > side presents their side of the story and nobody is free to counter > with the other side because of policy (and a reasonable policy at > that). And so the allegations just go unchallenged and are repeatedly > posted. What value does this add? At best it misleads people into > thinking that things like comrel actions are unfounded, and drives > away potential contributors. When a situation drives a way potential contributors, a closer look should happen. A split might be the wrong choice, but discussing the need for a remedy is good. > If these were discussions about policy in the abstract and not in the > specific then there wouldn't be as much difficulty (indeed, this is > the form our disagreement is taking right now). We can certainly have > a free conversation about whether somebody who sexually harasses > another developer ought to be booted or not. The problem comes in > when somebody has been the subject of a decision made based on their > individual behavior - there is no way to have a reasonable public > conversation about this. > > IMO discussions about individual comrel/etc decisions simply should > not be considered on-topic for our lists. Yes, but blocking of expression / communication is tricky: Within a particular organization (in this case, one focusing on FOSS/Libre software) demands that censorship be prevented at all costs VS expectation that disruption won't be tolerated, nor will general off-topic rudeness/disrespect, or even cruelty - some expression can only exist in good faith when it can be reasonably understood to further the overall objectives for the particular organization (in our case, gentoo) For a list specifically meant for development, more restrictions are a reasonable starting point than elsewhere. There has to be a line drawn somewhere, even if it's just "keep discussions limited to matters associated with the current thread" (germane) THIS discussion wouldn't make sense on a dev-util/cmake thread. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org
On 12/05/2017 05:18 PM, Nils Freydank wrote: > 5. Reasons for warnings and bans > --snip-- > c) spamming, i.e. flooding discussions with lots of messages in a row > d) constant postings off topic, i.e. disrupting discussions with unrelated > questions > (constant means more than two times in a row) Point #c versus #d #c - there can (and often are) good faith reasons for multiple postings "in a row", such as when responding to multiple threads, and/or to multiple posters within the same thread. Even just people who are awake (and would respond) at a time when other participants in the list would be sleeping could complicate this rule. #d - definition for constant seems unnecessary. For an alternative, maybe refine the definition to either use a 72 hour window or similar, or even just a basic expectation for discussion to be germane (on-topic) with refusal to stay on-topic (when warned) being the measure. Perhaps three strikes (per day?) are when the enforcement could start. parliament / congress and other formal assemblies have models for this. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/02/2017 06:18 PM, Michał Górny wrote: > II. This practically assumes that every new mailing list subscriber will > be able to recognize the problem. Otherwise, new people will repeatedly > be lured into discussing with them. > > III. In the end, it puts Gentoo in a bad position. Firstly, because it > silently consents to misbehavior on the mailing lists. Secondly, because > the lack of any statement in reply to accusations could be seen > as a sign of shameful silent admittance. > Can confirm: This was the first gentoo-dev thread I've ever posted to. I was frustrated in this thread mainly because I wasn't 100% certain if the persons who were making this thread - let's say "difficult" - I wasn't sure if they were developers/contributors, or just people who wandered into the list. archive readers might get confused too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/04/2017 01:51 PM, William L. Thomson Jr. wrote: > On Mon, 4 Dec 2017 13:15:32 + > "M. J. Everitt" wrote: > >> On 04/12/17 00:37, Matt Turner wrote: >>> A user requested I forward this information to the mailing list: >>> >>> http://www.hbs.edu/faculty/Publication%20Files/16-057_d45c0b4f-fa19-49de-8f1b-4b12fe054fea.pdf >>> https://goo.gl/42A8v7 (short URL of the same) >>> >>> ... and was itself cited a dozen or times: >>> >>> https://scholar.google.com/scholar?cites=5443947091657980238 >>> https://goo.gl/obvdzh (short URL of the same) > Anyone paying any attention to current events? Quite many business and > governments have gone out of their way to protect and hide the actions > of abusers. In most causes because they were money makers. I think that > may contradict the article entirely. > 1) harvard business school research publication, not an "article" 2) if things don't change, I'll be one of the people to quit. 3) gentoo already has documented instances of people leaving. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/04/2017 01:11 PM, Christopher Head wrote:
> On December 3, 2017 1:35:23 PM PST, "Michał Górny" wrote:
>> The best way to reach specific Gentoo developers is through Bugzilla.
>> This gives the best chance for focused discussion on the specific issue
>> without unnecessary distraction for other developers who are not
>> interested in the specific topic.
> While this is true for bugs, is it true for everything else
> as well? Bugzilla seems to me to be a more reactive, rather
> than proactive, tool when dealing with changes of behaviour
> in particular packages, eclasses, etc.
--snip--
> Bugzilla isn’t so easily discoverable, given the number of
> bugs filed; gentoo-dev has the nice property that the
> maintainers self-select which proposed changes are important
> enough to announce, which Bugzilla doesn’t do. So if I wanted
> to be notified of all important changes to core system
> packages on Bugzilla, today, I would have to (1) choose the
> set of packages to follow myself, probably missing a few in
> the process, and (2) filter out the unimportant bug mail
> which currently never reaches this list at all.
Reading the gentoo-dev list will still be an option. If there's
a bug already open for a planned change (as often happens when
blockers are expected, etc.), filing a bug and marking as a
blocker will be an option. If the behavior is known in
advance that it will break your configuration or workflow,
etc. I think it's still fine to file a bug about the oversight
before implemented occurs. If not appropriate to file as a bug,
there are project aliases you can mail concerns to.
{reference below}
On the other hand, if it's not obvious there will be breakage,
then posting to the gentoo-dev list can't prevent it. Also,
the original proposal did state that non-devs who contribute
can request post permission, as needed.
{reference below}
On 12/02/2017 06:18 PM, Michał Górny wrote:
> 1a. Subscription (reading) and archives will still be open.
>
> 1b. Active Gentoo contributors will be able to obtain posting access
> upon being vouched for by an active Gentoo developer.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/03/2017 08:19 PM, Peter Stuge wrote: > this 18 min talk by Donnie Berkholz from 2012, about Gentoo actually: Someone in private linked that video to me today. Yeah :( > Do not tolerate bad behavior by anyone! --snip-- > It is important to take action which clearly rejects > unacceptable behavior. Otherwise any behavior is per definition > implicitly accepted, which attracts assholes. You're not wrong. I've seen FOSS/Libre communities (and non-compsci peer-directed projects) fall apart when "radical free speech" went unchecked. The only people who stayed were even more effective when it came to what seemed like intentionally driving off anyone who dissented / spoke out against their disrespectful behaviors. > Coming back to the concrete proposal, I think a better course of > action is to demonstrate strong leadership, by speaking out in force > against bad behavior, every time. > > In order to have something to lean on, it can be super helpful to > have a code-of-conduct in place, and was already mentioned. --snip-- > I urge either ComRel or other leadership to take as forceful action > as is neccessary against bad behavior, to uphold a healthy > environment. > --snip-- > Please do not relent. It is not fair to yourself or your colleagues. > > > Thank you and keep up the excellent effort everyone > > //Peter Yes please. I don't want to see gentoo end because of ... rudeness. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists
On 12/03/2017 07:51 PM, Rich Freeman wrote:
> On Sun, Dec 3, 2017 at 7:37 PM, Matt Turner wrote:
>> With gentoo being a non-profit organization, an alternative way to
>> view it could be the trade-off of seeing developers / maintainers /
>> staff leave
> It isn't just the risk of leaving, but the risk of them never joining
> in the first place.
>
> If a flamewar goes back and forth, then it creates an environment
> {snip}
1) Yes. It's hard to recruit when the organization seems unpleasant.
2) The point of a dev list should be development. (not flames)
3) That paper has tables which are over my head. (but interesting)
4) Is this on more than list now? The subject line confused me.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
More than zero posts on this thread are consistent with this point: On 12/02/2017 06:18 PM, Michał Górny wrote: > 3. Support requests. Some of our 'expert users' have been abusing > the mailing lists to request support (because it's easier to ask > everyone than go through proper channels) and/or complain about bug > resolutions. This is a minor issue but still it is one. If things are a bug, it should be filed as a bug: when there's a fault, or a feature request, or any other thing which can go to the tracker, so b.g.o is the right place if it affects multiple configurations and needs addressed. Anything [mis]configuration related, or if it's unclear could likely go to an official support channel if it's gentoo-specific, or even upstream support. An expert user list would be a fine place for that too. Not all resolutions require a developer, and this likely includes misunderstandings or disagreements on how things were handled too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
1 / 1b seems reasonable for mitigating signal/noise issues. (previously unaware non-dev subscribers //currently// could post) On 12/02/2017 06:18 PM, Michał Górny wrote: > ...establish the following changes to the mailing lists: > > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be > initially restricted to active Gentoo developers. > > 1b. Active Gentoo contributors will be able to obtain posting access > upon being vouched for by an active Gentoo developer. signature.asc Description: OpenPGP digital signature
