On Mon, Sep 26, 2022 at 4:24 AM Guenther Meyer <[email protected]> wrote: > > On Tue, 20 Sep 2022 08:03:21 -0400 > "Bruce Ashfield" <[email protected]> wrote: > > > The patch itself looks fine, the only issue for easy processing is > > that it is attached to email, versus being the email. If you send the > > patch with git-send-email, it will take care of those details. > > I never used git-send-email - didn't know it - and I don't know if I > like it because of security reasons. I also thought it would be easier > to review/merge a patch if it is received as an attachment instead of > inline.
git send-email is heavily used, both in the OE ecosystem and many others. I'm not sure I follow what security concerns you might have with it .. but if you have anything specific let us know. Because it would affect all projects using it! As for attachments, they are harder to work with than inline patches. The tooling, replies, and well known (kernel-style) workflow is based around being able to reply inline and discuss patches. There's plenty of references for how the flow works, and I wouldn't do it justice by trying to paraphrase it here. > > So what is the workflow after a patch is received via email? Is there > some (automatic) tooling, or what is happening until a patch is merged? > It is a pretty standard maintainer workflow. I receive the patches, queue and test them. I have some of my own CI scripts, as do others that run against the repository. If a patch needs extra testing or longer to soak for comments, I'll often stage them in a master-next branch. For smaller changes, I often just pull them directly into master. I then follow up to let the submitter know the patch is merged, or provide change review feedback. > I'm accustomed to using the fork/commit/merge workflow that most > projects with github/gitlab repositories have. I guess there is nothing > like that (planned) in Yocto? > It depends on the repository, the project and the maintainer. For the patch volume on meta-virtualzation, the tried and true method of patches to the mailing list work. This aligns with OE core, poky and many of the other ecosystem layers. But like anything in an open source project .. it just depends. The different types of workflows are very well known by the overall yocto/OE project communities, and we've had some very long discussions on the topic. You can find them archives on the various OpenEmbedded Core or OpenEmbedded architecture mailing lists or in the minutes of the various in person summits we've had over the years. > Not that I want it currently, but who decides who will get commit > access to the Yocto repos? > There's no single yocto project repository. The project is an umbrella with many different subprojects, layers and maintainers. So push access varies by project. Most (if not all) of the projects work on a maintainer model. > > > That being said, don't worry about re-submitting it, I can detach the > > patch and apply it. > > Thanks for merging the patch into master! > Will the patch also be merged into kirkstone? What is the workflow here? > Either on submission of the patch, someone can indicate that the change is for master, and another branch. Or once it merges to master, they can follow up and ask for a backport to an older branch. In either case, the change needs to be a bugfix, versus a new feature. I consider this a request to backport, so I've cherry-picked the patch and merged it to kirkstone. Bruce > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#7629): https://lists.yoctoproject.org/g/meta-virtualization/message/7629 Mute This Topic: https://lists.yoctoproject.org/mt/93801075/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
