Quick summary ============= Requested attendees =================== Active developer: araujo, anyone who could talk about how to get this script running on Gentoo infra PMS: ciaranm, pkgcore dev, portage dev, any other tools that care about versions Enforced retirement: fmccor, musikc musikc has already informed us that she can't make it until an hour later, so this is the final topic. Roll call ========= (here, proxy [by whom] or slacker?) amne slacker [30 minutes late] betelgeuse here dberkholz here flameeyes here lu_zero here vapier proxy [solar] jokey here New process =========== The last few meetings have dragged out for hours unnecessarily. This time, let's return to moderating the channel. Let's try moderating during discussion of each topic, then temporarily opening the floor for that topic before a vote so anyone can contribute. Updates to last month's topics ============================== http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt Document of being an active developer ------------------------------------- Last month: No updates Updates: araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. He'd like to ask for approval of this design and discuss the script, in particular its infrastructure requirements. Suggestions on certificate content: -Add title to the top: "Developer Certification" -Add devrel contact info (general devrel email address) -Add link to devrel userinfo page -Add start and end dates to devrel retired developers page -Add a sentence saying e.g. "This certifies that XXX was a Gentoo developer from START_DATE to TODAY_DATE." The point is to avoid implying that the developer is certified forever, or will be a developer in the future. The information should be gotten from LDAP, for example using python-ldap. Could base this script on devrel's slacker script. It's unsure how signatures are going to happen, but one option is to keep a GPG-encrypted image of a signature and decrypt it on-demand for certificate creation. This should be discussed with the person doing the signing. Slacker arches -------------- 4 months ago: vapier will work on rich0's suggestion and repost it for discussion on -dev ML 2 months ago: vapier said he was going to work on it that weekend. Last month: No updates Updates: New topics ========== When are ChangeLog entries required? ------------------------------------ This question mainly relates to arch stabilizations. The consensus was that ChangeLog entries even for arch stabilizations provide valuable information that is unique without network access and more accessible than CVS logs even with network access. Some people were curious what proportion of space ChangeLogs take in the tree, but most people didn't think that was relevant. welp suggested making a changelog message part of repoman commit. It would be helpful for the QA team to help with checking for and enforcing ChangeLog messages. If that doesn't help matters, the council may have to take action. Can the council help fewer bugs get ignored by arm/sh/s390 teams? ----------------------------------------------------------------- The work happens, but Mart says it's not communicated to anyone and has no relationship to whether bugs are open. We need to understand the workflow of undermanned arch teams and see whether there's anything we can help improve. Possibly improving recuitment -- add a good, motivating staffing-needs entry. PMS: Are versions allowed to have more than 8 digits? ----------------------------------------------------- http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml https://bugs.gentoo.org/show_bug.cgi?id=188449 What do various PMs/tools support? Portage, Pkgcore, Paludis all handle <8. portage-utils does not but could be fixed to use longs instead of ints, with some loss of performance (magnitude unclear). versionator.eclass also needs fixing for >8 digits. Apparently [ ]-style tests break with large numbers, but [[ ]] works. Have to be careful which tests are getting used anywhere large versions are compared. The council generally favored allowing versions to have <=18 digits. This allows them to fit into 64 bits (18 signed digits or 19 unsigned) and gives them an upper bound, which some implementations of version parsing could find useful. We voted to do more research and testing, specifically to ask the package maintainers with extremely long PVs whether they were needed and to test the impact of extending versionator.eclass. Enforced retirement ------------------- What was the council's role in the recent enforced retirement of 3 developers? ---------------------------------------------------------------- The council received numerous complaints, agreed that the devrel lead could take action and discussed the problems with her. The council did not "force" her to claim its actions were hers. Why does the council permit such actions in apparent violation of Gentoo's policy of openness? ----------------------------------------------------------------- http://www.gentoo.org/foundation/en/#doc_chap2 says this: "Every aspect of Gentoo is and remains open. Gentoo does not benefit from hiding any of its development processes (whether it is source code or documentation, decisions or discussions, coordination or management)." Chris (wolf) noted that it does specifically refer to development process. Devrel's current process document also makes specific note of the lack of transparency, and disciplinary actions have historically been discussed in a closed environment, in part because of the potential harmful effects of the discussions if action is not taken. What is the council's role in an appeal? ---------------------------------------- How should we proceed with the current appeals? If the council is directly involved in disciplinary action, Ferris requests that we amend GLEP 39 to explain how the council handles appeals and whether the council can take direct disciplinary action. Open floor ----------