[sane-devel] sane-backends release 1.0.26 schedule

[Rolf Bensch]

Hi,

I see, the other work flows are pretty much easier for sane than git flow.

Am 20.05.2017 um 03:45 schrieb 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

I just pushed an doc update to master and created and pushed the branch
'pixma/mf240_adf_only_300dpi' with the corresponding bug fix. Outside
code freeze I'd have pushed the fix directly into master.

@Allan: You can decide if the branch can be merged into master before or
after the next release. If you won't merge it, I'll do it by myself
after the next release.
Background for this patch: The MF240 scanner supports only 300dpi for
adf scans. For this scanner I set the max. allowed value for adf scans
to 300dpi and activated and set the counterpart variable to 300dpi (min.
allowed value for adf scans). The activated variable is already in use
within other pixma sub-backends. This fix only affects the MF240 scanner.


>>>  - 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
>>>

If I wanted to ask someone to review the new branch, I'd named it as
'pixma/review/mf240_adf_only_300dpi'.

According to gitlab flow and github flow I would add these items:

- master is always 'stable'
  then the 'daily git snapshots' on the website can be renamed from
  'Unstable (Development) Source' to something like 'Stable Post Release
  source', I suppose that sane won't provide unstable sources in
  tarballs anymore
- releases, feature freeze and code freeze are tagged on master, e.g.
  RELEASE_1_0_27, FEATURE_FREEZE_PRE_1_0_27, CODE_FREEZE_PRE_1_0_27
  the restrictions for the freeze tags should be written into the tag
  message

>>
>> 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/
> 

>From my point of view, the new branch is a trial balloon for working
with and|or reviewing branches. Please feel free to define any naming
standard as you like.

Cheers,
Rolf