[sane-devel] sane-backends release 1.0.26 schedule

[Olaf Meeuwissen]

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