Hi, Rolf Bensch writes:
> Hi, > > > Am 19.05.2017 um 15:02 schrieb Olaf Meeuwissen: >> Hi All(an), >> >> m. allan noah writes: >> >>> What is the nature of the bug fix? Is it going to cause scanners that >>> worked with the prior release to be broken with this one? How big is >>> the fix? How likely to cause regressions? >> >> Here's where git branches come in nice. Rolf creates a branch, commits >> his bug fix and pushes the branch. Next, he informs the project admins >> of the bug fix branch and that he would like to see it included in the >> upcoming releases. The project admins have a look at the code changes >> and can decide for themselves and/or ask for more information as needs >> be. >> >> Right now, everything goes straight to master and I am not sure that is >> the best way to proceed when using git (Subversion and CVS are different >> beasts). I also realize that forcing everything through some sort of >> review process is unrealistic for sane-backends where most developers >> are rather focussed on their own backend(s) only. Maybe we should try >> to write up some kind of policy for pushing to master. >> >> Something like >> >> - pushing changes to master for a backend you maintain is okay (unless >> in code freeze) >> - pushing changes for code that affects multiple backends, something in >> sanei/ for example or the build system, should go to a branch and get >> reviewed before merging to master >> - anything you like to have an extra pair of eyes on goes to a branch >> and you ask/assign someone for review (uh-oh, Alioth doesn't support >> merge requests ... :-(, mail and/or mailing list for now?) >> - ... and some more for non-SANE developers that I'll skip for now >> > > In real life my company is using the gitflow structure to organize the > projects in git: > https://datasift.github.io/gitflow/IntroducingGitFlow.html . The > developer is free installing gitflow or not, but he|she must always > stick to the gitflow structure on the gitlab server. I'm aware of Git Flow. It has its good points but I tend to find it a bit over-engineered. Maybe for a big corporate project, yes, but for something like sane-backends I think it too complex. Something like GitLab Flow[1,2] (or GitHub Flow[3]) would be more suitable, IMHO, but with a few reasonably well-defined exceptions for the "no direct commits to master" rule (as I mentioned above). [1] https://docs.gitlab.com/ce/workflow/gitlab_flow.html [2] https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/ [3] https://guides.github.com/introduction/flow/ > Hope this helps. Me too, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join -- sane-devel mailing list: [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to [email protected]
