The following are the results of the survey "Gentoo: Portage repo usage survey and change evaluation" The survey was published as of 2016/02/01 04:00 UTC, and was locked for responses on 2016/02/21 04:00 UTC. 68 total responses. Responses by UTC date: 49 2016/02/01 9 2016/02/02 2 2016/02/03 3 2016/02/05 1 2016/02/07 1 2016/02/08 1 2016/02/09 1 2016/02/17 1 2016/02/18 Responses by UTC hour: 2 00 0 01 1 02 2 03 1 04 2 05 10 06 5 07 4 08 3 09 1 10 9 11 6 12 3 13 1 14 1 15 1 16 3 17 1 18 4 19 5 21 2 22 1 23 Q1: How do you use Portage package changelogs? (question-type: checkbox / select all that apply; with OTHER) (68 responses) A1.1: I don't read them at all A1.2: I read them online. A1.3: I read them with emerge -p -l A1.4: I read them in a text editor A1.5: I read them with less/more/head/tail (or other reader) A1.6: I use them to laugh at Gentoo because I run another distro A1.7: Other Number of responses selecting each answer: 28 "A1.5" 24 "A1.4" 19 "A1.1" 16 "A1.2" 5 "A1.3" 1 "Since they've been broken, I've started keeping the git repo on the side and reading them there; this is not ideal and hugely wasteful, since now I'm syncing twice." 1 "porthole's Highlighted changelog view" 1 "only used when not in git or really old" 1 "Now that I know about the -l option of emerge, I think I'll start doing this, too, rather than manually opening text files or looking up changes via the site." 1 "I use the git tree where they don't exist (and read git log)" 1 "I read the stuff from 'eix-sync' output" 1 "I read the git history on a full checkout." 1 "I read git log" 1 "In Kuroo (Portage GUI)" 1 "Infrequently, only when I'm trying to find why there is a revbump or similar do I look up ChangeLogs" 1 "git log /var/db/ebuilds/gentoo/cat/pkg" 1 "git" 1 "equery c" Response combinations (count, answers): 14 "A1.1" 11 "A1.5" 8 "A1.4" 5 "A1.4; A1.5" 5 "A1.2" 4 "A1.2; A1.4" 2 "A1.3; A1.4; A1.5" 2 "A1.2; A1.4; A1.5" 1 "porthole's Highlighted changelog view" 1 "I read the stuff from 'eix-sync' output" 1 "I read the git history on a full checkout." 1 "Infrequently, only when I'm trying to find why there is a revbump or similar do I look up ChangeLogs" 1 "A1.5; equery c" 1 "A1.4; A1.5; In Kuroo (Portage GUI)" 1 "A1.3; A1.5; Since they've been broken, I've started keeping the git repo on the side and reading them there; this is not ideal and hugely wasteful, since now I'm syncing twice." 1 "A1.3; A1.5" 1 "A1.2; git" 1 "A1.2; A1.5; Now that I know about the -l option of emerge, I think I'll start doing this, too, rather than manually opening text files or looking up changes via the site." 1 "A1.2; A1.5" 1 "A1.2; A1.3; A1.4; A1.5" 1 "A1.1; I use the git tree where they don't exist (and read git log)" 1 "A1.1; I read git log" 1 "A1.1; git log /var/db/ebuilds/gentoo/cat/pkg" 1 "A1.1; A1.5" 1 "A1.1; A1.2; A1.4; only used when not in git or really old" Q2: Reduce local disk usage by excluding ChangeLogs? (question-type: option / select one; with OTHER) (68 responses) Number of responses selecting each answer: 19 "Yes, unconditionally; get rid of ChangeLogs!" 19 "No, but only if were optional (I do NOT want it, but others might)" 18 "Yes, but only if it were optional (I want it, but others might NOT)" 6 "No, unconditionally; ChangeLogs should ALWAYS be present." 1 "Yes, get rid of unconditionally, but provide a means of viewing them easily online" 1 "Unconditionally keep ~2 last years of ChangeLogs only" 1 "Rewrite the builtin emerge -l to fetch the logs remotely, and pull them up in LOG_READER_APP, or some such variable." 1 "Exclude from git as they are redundant there (already the case)" 1 "don't really care" 1 "cmd-line tool to get the changelog of a particular packet from a server" Q3: What order should ChangeLog entries be in? (question-type: option / select one; with OTHER) (68 responses) Number of responses selecting each answer: 25 "I'd prefer newest entries first, but do what is best for distribution" 17 "Newest entries should be first!" 14 "I don't care" 8 "Get rid of ChangeLogs!" 2 "Oldest entries should be first!" 1 "Whatever works with equery c" 1 "I like newest first, but Git/VCS gives me that -- AXE CHANGELOGS" Q4: Provide a read-only git repo with ALL metadata & additional content (question-type: option / select one) (68 responses) Number of responses selecting each answer: 25 "No, I would not use this, but somebody else might. (SOFT-NO)" 22 "Undecided." 18 "Yes, I would use this. (HARD-YES)" 3 "No, nobody would use this. (HARD-NO)" Q5: Freeform input about distribution of the Portage tree (question-type: text) (17 responses) A: "Nearly six months have passed since the CVS -> git migration, and the quality of rsync distribution has never really recovered. It seems like this should have been higher priority, but I am hopeful that some day soon the users will have uncompromised ability to sync again, free from Manifest issues and upside down ChangeLogs." A: "While I do like and miss the old changelogs, newest first. I am slowly adapting to gathering that info via the git tree and git log. It should also be possible to adapt the Changelog view to a git based tree and parsing git log output for a pkg path. So I am open to all the possibilities." A: "I have heared of people using 'git clone --depth 1' because it is faster then rsync and has no local history. Wouldn't that be an option for use with the read-only git repo to further save space?" A: "The portage tree really needs strong cryptographic integrity protection and verification (e.g. GLEP 58)" A: "as an alternative to a repo with packages+all metadata, I would quite like to have a repo of only metadata/. I want to use the dev portage tree and use a submodule for the metadata/ stuff so I get the md5-cache and the rest git submodule add -b master anongit.g.o/gentoo-metadata.git will add the submodule and make it track the branch. then we can teach emerge --sync to run: git submodule update --remote https://stackoverflow.com/questions/9189575/git-submodule-tracking-latest/9189815#9189815" A: "I miss Date of first creation or author info in ebuild..at times..like the simplicity oF current sync process " A: "I use snapshots exclusively, and consider changelogs essential." A: "I've always been a fan of not fixing things that aren't broken" A: "I would prefer that rsync does _not_ go away, git is more setup, and has some limitations that rsync does not. With rsync it is possible to only sync specific portions of the tree, and exclude certain paths etc. With git, it is basically the whole tree or nothing." A: "Don't call it the portage tree, call it the Gentoo repo or Gentoo tree, other than that, as long as the option is simple and reliable, I don't care too much about anything else." A: "No complaints. A developer-focused guide on using gentoo.git as /usr/portage would be great. The best we have presently is hasufell's repo. It's good, but something more official would be even better. If that's not a preferred approach, suggestions for how developers should manage their copy of the tree and develop ebuilds would be useful. The more people we have using direct-from-Git, the faster we can iron out bugs." A: "Transfer size reduction: Let portage prefer rsync servers that support compression, or have separate DNS rotation for them" A: "squashfs instead of (or in addition to) tarballs" A: "If a git repo with metadata could be less CPU and bandwidth consuming than the existing rsync infrastructure (even if improved with optional ChangeLog removals and whatnot), perhaps it would be worth heading that way as the default advertised method eventually" A: "Leave rsync to the average user to sync fast with the latest state of the tree (without useless overhead for the user). Developers may use git with full tree history in separate directories. Changelogs are better readable online." A: "I personally use this: https://github.com/hasufell/portage-gentoo-git-config" Q6: Freeform input about the structure of the Portage tree. (question-type: text) (7 responses) A: "Okay as-is." A: "see above" A: "git is great :)" A: "As with the previous, simple and reliable is my desire." A: "No complaints; however I'd like to see more guides appear on the wiki for manipulating the tree, such as scripts that users can use to generate changelogs or get better-detailed history on specific packages, etc. There are tools and guides out there, but their discoverability is low and I believe that to negatively impact the productivity of both developers and users." "that's ok" A: "Developer direct usage of GIT tree could be nicer and perhaps better documented. Including how to set up GLSA metadata and what are the implications of not using rsync (metadata/ files vs emerge --regen vs egencache); might involve relocating some of that data to not be as subdirectories of the main gentoo.git tree" Q7: May we contact you for further input/clarifications: (question-type: text) (19 responses) Exact responses redacted for private, stats as follows: 7 @gentoo.org email addresses 7 other email addresses (not active or retired developers) 3 "Yes" responses with no contact info! 1 retired gentoo developer (address matching LDAP) 1 Other response