Re: Some ideas for process improvements/changes
Hi, On Thu, 2023-10-19 at 18:13 +0200, Mark Wielaard wrote: > > - Get rid of ChangeLog files and trivial ChangeLog entries > > I personally love ChangeLog entries. Writing them helps me > > double check I actually intended to make the changes. And > > it is a great help reviewing patches. It helps having to > > guess if some specific change was an accident or intended. > > > > But patches that have changes against the ChangeLog files are > > sometimes hard to rebase or move between branches. The gnulib > > git-merge-changelog driver is awesome, but is not always able > > to help. Also some commit messages for smaller changes are > > already fine describing what changed. > > > > So I propose to drop ChangeLog files completely and only add > > a ChangeLog entry to the commit message for larger changes > > to help the review process. > > Some, but not all contributors have now switched to this style of > commits. The attached patch formally documents it. > > > - Use patchwork more > > All patches sent to the mailing list are tracked at > > https://patchwork.sourceware.org/project/elfutils/list/ > > It has helped me a lot keeping track of patches that > > have been pending for some time. Also git-pw has been > > really nice for cherry-picking patches. > > https://patchwork.readthedocs.io/projects/git-pw/en/latest/ > > > > Please let me know if you would like to help maintain the > > pending patch list and I'll add your account as maintainer > > for the elfutils project. > > > > For using it with git-pw use these .git/config settings: > > [pw] > > server = https://patchwork.sourceware.org/api/1.2/ > > project = elfutils > > token = > > states = committed,accepted,superseded,deferred,rejected,under-review > > > > It would be nice if it was automated a bit more by have a git > > commit hook that flagged whether a patch was committed. And if > > the buildbot try-branch system would flag pass/fail on the patch. > > The automation is still not there. But I am using it happily as todo > list: https://patchwork.sourceware.org/project/elfutils/list/ > Currently it lists 42 active patches, so we could use some help with > reviewing. If anybody want to become a elfutils patchwork maintainer > please let me know. Also documented in CONTRIBUTING in the attached > patch. Given nobody complained (and people seem happy with the above changes) I have committed those changes to CONTRIBUTING now. Cheers, Mark > There are two more changes I like to make, but not right now. > > As part of the release (just before, or right after) later this month I > like to switch the main branch from 'master' to 'main'. It is the last > use of some harmful language in our project. > https://inclusivenaming.org/ > It will need a few updates to the documentation and buildbot setup. But > we can leave an alias so nothing breaks. > > Finally we do have a somewhat informal code of conduct, see the end of > our CONTRIBUTING document: > >committers/maintainers who repeatedly ignore the above guidelines, >are hostile or offensive towards other committers or contributors, >and don't correct their behavior after being asked by other committers >will be removed as maintainer/committer. > > It would imho be good to extend this a little to all project > contributors and adopt a formal code of conduct like the Contributor > Covenant https://www.contributor-covenant.org/ > That page also has some good references on reaching agreement on > adopting such a more formal code of conduct. > > Please let me know if you would like to help adopting a more formal > code of conduct and/or be part of a code of conduct committee for > elfutils. > > Thanks, > > Mark
☺ Buildbot (Sourceware): elfutils - build successful (master)
A restored build has been detected on builder elfutils-gentoo-sparc while building elfutils. Full details are available at: https://builder.sourceware.org/buildbot/#builders/225/builds/113 Build state: build successful Revision: f23a30d52119c3a94b6e83a45420d4d973d417e0 Worker: gentoo-sparc Build Reason: (unknown) Blamelist: Housam Alamour , Mark Wielaard Steps: - 0: worker_preparation ( success ) - 1: set package name ( success ) - 2: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/2/logs/stdio - 3: autoreconf ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/3/logs/stdio - 4: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/4/logs/stdio - config.log: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/4/logs/config_log - 5: get version ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/5/logs/stdio - property changes: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/5/logs/property_changes - 6: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/6/logs/stdio - warnings (3): https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/6/logs/warnings__3_ - 7: make check ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/7/logs/stdio - test-suite.log: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/7/logs/test-suite_log - 8: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/8/logs/stdio - 9: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/9/logs/stdio - 10: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/10/logs/stdio - 11: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/11/logs/stdio - 12: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/12/logs/stdio - 13: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/13/logs/stdio - 14: pass .bunsen.source.gitbranch ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/14/logs/stdio - 15: pass .bunsen.source.gitrepo ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/15/logs/stdio - 16: upload to bunsen ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/16/logs/stdio - 17: clean up ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/17/logs/stdio - 18: make distclean ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/225/builds/113/steps/18/logs/stdio
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #3 from Frank Ch. Eigler --- Is there some reason not to just bump up that bitfield width from :24 to :32 or more for now, until a deeper analysis of llvm informs us as to how wide these discriminator codes can really be? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30991] - srcfiles tarball feature
https://sourceware.org/bugzilla/show_bug.cgi?id=30991 Housam Alamour changed: What|Removed |Added Summary|Bug 30010 - srcfiles|- srcfiles tarball feature |tarball feature | -- You are receiving this mail because: You are on the CC list for the bug.
