[sane-devel] [ITR] Intent To Release: sane-backends-1.0.28

Povilas Kanapickas povilas at radix.lt
Wed Jul 10 00:37:17 BST 2019


Hi Olaf,

On 2019-06-26 16:29, Olaf Meeuwissen wrote:
>  [2]: https://gitlab.com/sane-project/backends/-/milestones/2
> 
> In terms of timeline, things look like this (for those of you who can't
> be bothered to follow the link :wink:):
> 
>   | Date       | Phase                   |
>   |:----------:|:------------------------|
>   | 2019-06-26 | Kick-off                |
>   | 2019-07-10 | Feature freeze          |
>   | 2019-07-24 | Code freeze             |
>   | 2019-07-31 | Release :confetti_ball: |

I'm wondering, would it make sense to branch off to a separate release
branch at the beginning of the feature freeze and then apply the freeze
only for that branch? That way the release branch would still stabilize
yet the work on the master branch could continue.

The code freeze makes most sense when branching off makes fixes harder
as they need to be applied to two places. Ever since we moved to git
this argument has much less weight as cherry-picking in git is very easy.

Of course, this change is probably too late for this release, but we
could perhaps consider this suggestion for the next one.

Regards,
Povilas

> I'm still mostly going by what's in [doc/releases.txt][3] but will
> update that as I see fit.  Some of the info in there is no longer
> relevant, some of it can be scripted away in our CI (or so I think
> and I'll be testing that in a private fork).
> 
>  [3]: https://gitlab.com/sane-project/backends/blob/master/doc/releases.txt
> 
> For you project members, please have a look at the open merge requests
> and open issues that have been assigned to you.  If any of those
> are/look accomplishable within the timetable of the milestone, feel free
> to add them to the milestone.  If you do, you're also expected to take
> care of the merge request or issue within the timetable above, for
> obvious reasons, I hope.
> 
> Next, for any [unassigned merge requests][4] and [unassigned issues][5]
> have a look at whether this could be taken care of for 1.0.28.  If so,
> self-assign and add them to the milestone.  If not, just leave them as
> they are.
> 
>  [4]: https://gitlab.com/sane-project/backends/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None
>  [5]: https://gitlab.com/sane-project/backends/issues?scope=all&utf8=%E2%9C%93&state=opened&assignee_id=None
> 
> Hope this helps,
> --
> 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
> 




More information about the sane-devel mailing list