Re: [sane-devel] [ITR] Intent To Release: sane-backends-1.0.28
Hi all, On 2019-07-12 21:12, Rolf Bensch wrote: > Hi Olaf, > > Am 10.07.19 um 13:37 schrieb Olaf Meeuwissen: >> >> Thanks for bringing this up. I agree with considering this for the next >> one. I'd really like to move to semantic versioning. That way we can >> make a 1.1 branch at "feature freeze" and only add bug fixes there. >> Preferably via cherry-picking from master but other flows are possible. >> >> New features can go to master any time they're ready. >> > I'd like to see something like a simplified git-flow: > > master - for releases > develop - all ongoing development (source for git snapshot) > release branches - created on develop @ feature freeze > - may contain tags like "1.28.0-code_freeze" > - merge to develop if necessary > - merge to master if ready > > All merges should be done with the option --no-ff . > I second this option. Another semi-related thing I'd like us to consider: what about forbidding direct pushes to the master/develop branch and only allowing pull requests even if the developer will merge them himself without additional review? This will ensure that the CI gets a chance to run. With the current direct-push-to-master approach I see many chances where the CI could break. Additionally, if something breaks later the pull request page is a very clear place where the discussion (if needed) could take place. Regards, Povilas -- sane-devel mailing list: sane-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
Re: [sane-devel] [ITR] Intent To Release: sane-backends-1.0.28
Hi Olaf, Am 10.07.19 um 13:37 schrieb Olaf Meeuwissen: > > Thanks for bringing this up. I agree with considering this for the next > one. I'd really like to move to semantic versioning. That way we can > make a 1.1 branch at "feature freeze" and only add bug fixes there. > Preferably via cherry-picking from master but other flows are possible. > > New features can go to master any time they're ready. > I'd like to see something like a simplified git-flow: master - for releases develop - all ongoing development (source for git snapshot) release branches - created on develop @ feature freeze - may contain tags like "1.28.0-code_freeze" - merge to develop if necessary - merge to master if ready All merges should be done with the option --no-ff . Cheers, Rolf -- sane-devel mailing list: sane-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
Re: [sane-devel] [ITR] Intent To Release: sane-backends-1.0.28
Hi Povilas, Povilas Kanapickas writes: > 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. Thanks for bringing this up. I agree with considering this for the next one. I'd really like to move to semantic versioning. That way we can make a 1.1 branch at "feature freeze" and only add bug fixes there. Preferably via cherry-picking from master but other flows are possible. New features can go to master any time they're ready. Anyway, that's for later. Let's focus on 1.0.28 now. -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join -- sane-devel mailing list: sane-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
Re: [sane-devel] [ITR] Intent To Release: sane-backends-1.0.28
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=%E2%9C%93=opened_id=None > [5]: > https://gitlab.com/sane-project/backends/issues?scope=all=%E2%9C%93=opened_id=None > > Hope this helps, > -- > Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 > GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 > Support Free Softwarehttps://my.fsf.org/donate > Join the Free Software Foundation https://my.fsf.org/join > -- sane-devel mailing list: sane-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
