[prev in list] [next in list] [prev in thread] [next in thread]
List: flashrom
Subject: [flashrom] Re: Release preparations
From: Martin L Roth <gaumless () gmail ! com>
Date: 2022-04-29 16:14:27
Message-ID: CA+e+Ov5WZ7QhqhiV=wELCM3wNVLu8+ivQy0fy85AyL8g8ehwHQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Apr 28, 2022 at 9:36 PM Felix Singer <felixsinger@posteo.net> wrote:
> On Thu, 2022-04-28 at 08:22 -0400, Greg Troxel wrote:
> >
> > Anastasia Klimchuk <aklm@chromium.org> writes:
> >
> > > I haven't done any releases before, so tell me if I am wrong. But
> > > what I am thinking when looking at the list of issues: maybe we can
> > > have some time for "just fixing issues on master" and after that do
> > > a release branch? Does it make sense? "Some time" won't take
> > > forever (AU winter maybe?). I have issue #353 assigned to me, so
> > > now it has to happen :)
> >
> > My $0.02 from dealing with various projects.
> >
> > Flashrom is small and I think it's best to do the release off master,
> > getting everything done that needs to get done, and then beginning
> > the process with feature freeze, moving to regression and doc fixes
> > only, maybe alpha, beta, rc and then release. Only when there is a
> > release create a branch that would be used for micro updates to the
> > release while master is back open for development.
>
I think this depends on what's happening for the release. If code is just
being added, the master branch is fine. It sounded like there might be a
desire to remove code to do the release. In that case it probably makes
sense to get as close to the release as possible, branch, then remove any
code necessary for the release to happen. After the code is removed, maybe
only allow stabilization changes and bugfixes onto that branch.
> > In order to make a release it is necessary to say no to further
> > changes. It is always possible to improve, but that leads to never
> > releasing, and users are better served with a series of better
> > releases, as long as each one does not have significant
> > regressions. This is easy to say and hard to do!
> >
> > Creating a release branch before release means changes happen in
> > master disconnected from release and there's backporting effort and a
> > lot more work. Not branching incentivizes everyone to get the release
> > done and hold their feature branches.
>
> Good thoughts. Though, I think we shouldn't think about the actual
> release process too much now, because there are many issues from the
> past open and many questions unanswered.
>
> For now, we should just focus on indentifying major issues, fixing
> these and see how that goes. Moving the issues Nico mentioned to the
> ticket system is a good first step. It could take some time until the
> actual release process can start, since I think there is lots of work
> to do to get to this point. However, things might look totally
> different in some weeks or months and so I would postpone this
> discussion. It doesn't make much sense to me to do that now.
>
I agree that it's too early to actually start the release process. It's
good to have a well defined process though, so that should probably start
now, before it's needed.
Maybe look over the coreboot release process and see what's useful to take
from that.
https://doc.coreboot.org/releases/checklist.html
Keep in mind though that coreboot releases are more of a snapshot of the
codebase at a certain point in time than an actual stabilized release, so
I'd imagine flashrom might want to do something like a testing checklist.
Martin
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Apr 28, 2022 at 9:36 PM Felix Singer <<a \
href="mailto:felixsinger@posteo.net">felixsinger@posteo.net</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2022-04-28 at \
08:22 -0400, Greg Troxel wrote:<br> > <br>
> Anastasia Klimchuk <<a href="mailto:aklm@chromium.org" \
target="_blank">aklm@chromium.org</a>> writes:<br> > <br>
> > I haven't done any releases before, so tell me if I am wrong. But<br>
> > what I am thinking when looking at the list of issues: maybe we can<br>
> > have some time for "just fixing issues on master" and after that do<br>
> > a release branch? Does it make sense? "Some time" won't take<br>
> > forever (AU winter maybe?). I have issue #353 assigned to me, so<br>
> > now it has to happen :)<br>
> <br>
> My $0.02 from dealing with various projects.<br>
> <br>
> Flashrom is small and I think it's best to do the release off master,<br>
> getting everything done that needs to get done, and then beginning<br>
> the process with feature freeze, moving to regression and doc fixes<br>
> only, maybe alpha, beta, rc and then release. Only when there is a<br>
> release create a branch that would be used for micro updates to the<br>
> release while master is back open for \
development.<br></blockquote><div><br></div><div>I think this depends on what's \
happening for the release. If code is just being added, the master branch is fine. \
It sounded like there might be a desire to remove code to do the release. In that \
case it probably makes sense to get as close to the release as possible, branch, then \
remove any code necessary for the release to happen. After the code is removed, \
maybe only allow stabilization changes and bugfixes onto that branch.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> > In order to make a release it is \
necessary to say no to further<br> > changes. It is always possible to improve, \
but that leads to never<br> > releasing, and users are better served with a series \
of better<br> > releases, as long as each one does not have significant<br>
> regressions. This is easy to say and hard to do!<br>
> <br>
> Creating a release branch before release means changes happen in<br>
> master disconnected from release and there's backporting effort and a<br>
> lot more work. Not branching incentivizes everyone to get the release<br>
> done and hold their feature branches.<br>
<br>
Good thoughts. Though, I think we shouldn't think about the actual<br>
release process too much now, because there are many issues from the<br>
past open and many questions unanswered.<br>
<br>
For now, we should just focus on indentifying major issues, fixing<br>
these and see how that goes. Moving the issues Nico mentioned to the<br>
ticket system is a good first step. It could take some time until the<br>
actual release process can start, since I think there is lots of work<br>
to do to get to this point. However, things might look totally<br>
different in some weeks or months and so I would postpone this<br>
discussion. It doesn't make much sense to me to do that \
now.<br></blockquote><div><br></div><div>I agree that it's too early to actually \
start the release process. It's good to have a well defined process though, so \
that should probably start now, before it's \
needed.</div><div><br></div><div>Maybe look over the coreboot release process and see \
what's useful to take from that.</div><div><a \
href="https://doc.coreboot.org/releases/checklist.html">https://doc.coreboot.org/releases/checklist.html</a></div><div><br></div><div>Keep \
in mind though that coreboot releases are more of a snapshot of the codebase at a \
certain point in time than an actual stabilized release, so I'd imagine flashrom \
might want to do something like a testing \
checklist.</div><div><br></div><div>Martin</div><div> </div></div></div>
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-leave@flashrom.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic