Re: Improving our frequency of (patch) releases, and letting committers make releases
> I believe some basic distribution changes would greatly help the entire > question here, including making release builds easier for other people > to perform, shortening the cycle times as desired. If there is some > interest in building releases, I would like some help solving the > problems that exist and have been in JIRA for quite some time. Or we can just say that committers can make releases, and the KEYS file can change. These tickets can be improvements later, rather than blockers now. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: moving the site from SVN to git
Thanks, Jon! From: Jon Haddad Sent: Thursday, October 17, 2019 7:07 AM To: dev@cassandra.apache.org Subject: Re: moving the site from SVN to git The migration is finished. I had to fix a few things along the way. The docker containers didn't build correctly (based on debian:latest rather than a fixed tag), and the site had to be served out of the content directory rather than the publish one we were using. I'm going to address a couple things as follow ups. We still point people to IRC, I'll update that to slack. Longer term I'll migrate it to Hugo, which will make the entire process a lot easier. Jon On Wed, Oct 9, 2019 at 10:26 PM Jon Haddad wrote: > OK, I checked with INFRA on some details and will finish the migration > tomorrow. > > On Thu, Oct 3, 2019 at 11:32 AM Jon Haddad wrote: > >> Awesome, thanks Michael. >> >> We need to do a little bit of additional configuration to have it switch >> over. Specifically, we need to set up the .asf.yaml config to tell the >> servers how the site should be published. I can take care of it >> tomorrow. >> >> Reference: >> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Publishingabranchtoyourprojectwebsite >> >> On Thu, Oct 3, 2019 at 10:57 AM Michael Shuler >> wrote: >> >>> committed! :) >>> >>> https://gitbox.apache.org/repos/asf?p=cassandra-website.git >>> >>> Michael >>> >>> On 10/3/19 12:22 PM, Jon Haddad wrote: >>> > I think we can safely ignore them. Thanks for figuring this out. >>> > >>> > On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler >> > >>> > wrote: >>> > >>> >> I'm making progress through many periodic timeouts to svn.a.o and >>> >> restarts, but it appears that svn2git is smart enough to pick up where >>> >> it left off. The first commit captured at the svn path I'm specifying >>> is >>> >> when Cassandra was moved to a top level project at r922689 >>> (2010-03-13). >>> >> I don't know the old incubator path, and it's probably OK to ignore >>> the >>> >> few older incubator commits? I imagine it would mean starting over the >>> >> entire import to pull in those older incubator svn commits, then >>> >> changing the url and somehow importing the newer path on top? >>> >> >>> >> I tried using a local path as the source to try to speed things up, >>> >> after I got my first few timeouts, but that fails. >>> >> >>> >> Curious if anyone really cares if we lose a few early commits - if >>> so, I >>> >> can try to figure out the old path and start again. >>> >> >>> >> Michael >>> >> >>> >> On 10/3/19 11:14 AM, Jon Haddad wrote: >>> >>> Thanks for taking a look, Michael. Hopefully you have better luck >>> than >>> >> me >>> >>> :) >>> >>> >>> >>> On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler < >>> mich...@pbandjelly.org> >>> >>> wrote: >>> >>> >>> I cloned the empty cassandra-website git repo, and I'm running: >>> >>> svn2git http://svn.apache.org/repos/asf/cassandra/site >>> --rootistrunk >>> --no-minimize-url >>> >>> ..to see what I get. An svn checkout of the above url says it's only >>> 69M, so I suppose it's pulling all history of all time for all >>> projects? >>> >>> I'll let this roll for a while I run an errand and report back! >>> >>> Michael >>> >>> On 10/2/19 9:30 PM, Jon Haddad wrote: >>> > Daniel referred me to the GitBox self service system. >>> > >>> > I've attempted to port the site over using the tool Michael >>> suggested, >>> but >>> > after a couple hours it died with this message: >>> > >>> > command failed: r922600 >>> > git checkout -f master >>> > >>> > If either of you (Mick or Michael) want to give svn2git a shot >>> maybe >>> you'll >>> > get a different result.I think it may have been due to the >>> large >>> >> size >>> > of the repo and the small drive on the VM I was using. I can try >>> it >>> again >>> > tomorrow with more storage to see if I get a better result. Mick >>> if >>> >> you >>> > want to give it a shot in the meantime that would be appreciated. >>> > >>> > Jon >>> > >>> > On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad >>> wrote: >>> > >>> >> I created an INFRA ticket here: >>> >> https://issues.apache.org/jira/browse/INFRA-19218. >>> >> >>> >> On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler < >>> >> mich...@pbandjelly.org> >>> >> wrote: >>> >> >>> >>> I see no good reason to trash history. There are tools to make >>> moving >>> >>> from svn to git (hopefully) painless. We used git-svn for the >>> main c* >>> >>> source to retain history of both, which this tool uses to do >>> >> migrations >>> >>> - https://github.com/nirvdrum/svn2git >>> >>> >>> >>> Michael >>> >>> >>> >>> On 9/25/19 12:57 AM, Mick Semb Wever wrote: >>> >>> > Personally, no, I don't.
Re: Improving our frequency of (patch) releases, and letting committers make releases
Oh! As an added bonus of migrating to proper bintray package repository types, we also cure the pain of users attempting to install older versions than the latest release, since all versions in the suite are installable. -- Michael On 10/17/19 9:47 AM, Michael Shuler wrote: Noted: https://issues.apache.org/jira/browse/CASSANDRA-14963 Fundamental current docker build flaws: https://issues.apache.org/jira/browse/CASSANDRA-14962 Distribution changes suggested for deb/rpm: https://issues.apache.org/jira/browse/CASSANDRA-14966 https://issues.apache.org/jira/browse/CASSANDRA-14967 ..which are dependencies of repository sig changes to solve the whole KEYS file pain for package users, for ever and ever: https://issues.apache.org/jira/browse/CASSANDRA-14968 There are other ASF projects using bintray metatdata signing (the repo metadata is *not* a release artifact). Artifact sigs uploaded to /dist/ and subsequent verification from KEYS seem orthogonal to repo metadata signatures to me. I don't see why we cannot do the same as quite a few other projects and use automated bintray repo signing, migrating to appropriate bintray repository types. I believe some basic distribution changes would greatly help the entire question here, including making release builds easier for other people to perform, shortening the cycle times as desired. If there is some interest in building releases, I would like some help solving the problems that exist and have been in JIRA for quite some time. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Improving our frequency of (patch) releases, and letting committers make releases
Noted: https://issues.apache.org/jira/browse/CASSANDRA-14963 Fundamental current docker build flaws: https://issues.apache.org/jira/browse/CASSANDRA-14962 Distribution changes suggested for deb/rpm: https://issues.apache.org/jira/browse/CASSANDRA-14966 https://issues.apache.org/jira/browse/CASSANDRA-14967 ..which are dependencies of repository sig changes to solve the whole KEYS file pain for package users, for ever and ever: https://issues.apache.org/jira/browse/CASSANDRA-14968 There are other ASF projects using bintray metatdata signing (the repo metadata is *not* a release artifact). Artifact sigs uploaded to /dist/ and subsequent verification from KEYS seem orthogonal to repo metadata signatures to me. I don't see why we cannot do the same as quite a few other projects and use automated bintray repo signing, migrating to appropriate bintray repository types. I believe some basic distribution changes would greatly help the entire question here, including making release builds easier for other people to perform, shortening the cycle times as desired. If there is some interest in building releases, I would like some help solving the problems that exist and have been in JIRA for quite some time. -- Kind regards, Michael On 10/17/19 8:41 AM, Joshua McKenzie wrote: Might make sense to split the difference and have a loose reactive policy of "consider / discuss a potential release when any of the following are hit": 1. something critical is merged (data loss fix, cluster down fix, etc) 2. there are changes to the branch 3. it's been weeks since the last patch Maybe having triggers at reasonably fat M/N above (30/8?) would be enough to trigger those conversations and keep momentum on releases while respecting both the highly variable delta each change can have as well as our variable resources to commit to release validation across the project as contributors. On Thu, Oct 17, 2019 at 8:23 AM Jon Haddad wrote: Mick's absolutely right. Even if we had been doing more frequent releases, it's a big risk for us to only have one person able to it in the first place. I also agree with Benedict. I don't think we need to be crazy strict about windows. As long as we tell folks they may need to import keys, I think we're much better off than we are now. On Thu, Oct 17, 2019 at 5:08 AM Benedict Elliott Smith < bened...@apache.org> wrote: +1 We need to do something about this, and I don't mind what. It would be better if we cut fix releases immediately after a critical fix lands, much as we used to. We've got fairly lazy about producing releases, perhaps because many of the full-time contributors now work for organisations that don't really need them. We should definitely add any willing volunteers to the KEYS file now. I don't personally think we need any kind of a strict policy about modifying it in future, except that if our release cadence drops and we have willing volunteers we should do it again. On 17/10/2019, 07:50, "Mick Semb Wever" wrote: > We're still in the position where only four people in the project: > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > release. Our current patch release frequency is lacking. It's been 8 months since 3.11.4. This is having an impact on users and their faith in the technology. There is currently only one person in the community that is actively making releases. This really doesn't inspire confidence. We really should be cutting a patch release every 2 to 6 weeks, if critical fixes apply, imho. And I for one would certainly like to be helping out with this situation. If we choose to address this issue, there are two facets to it that come to mind: 1) This misnomer that committers can't cut and publish releases. 2) That we can't make changes to the KEYS file (or that it's too painful to do so). Re (1). I'm not sure where this misunderstanding came from in our community. But the ASF policy does not prevent committers from being the release manager. By default the only thing in the process a committer can't do is publish the successfully voted upon release from stage to public. This is a one-line svn command and the last and very small action in the release process at large. A committer can coordinate, cut, stage, announce, and initiate the vote on a release, which is the bulk of the work. And the committer can also do the final publish command if the PMC has voted that this is ok in this community. This is all in http://www.apache.org/legal/release-policy.html > Is it time to add more people to our KEYS file? > This will have the consequence that debian users will have to re-add it. Re (2), the problem is that changes to the KEYS file mean that debian users have to re-import it before pulling new packages. But is that really worse than an 8 month or more for an earlier patch version like ".5" ? > But
Re: moving the site from SVN to git
The migration is finished. I had to fix a few things along the way. The docker containers didn't build correctly (based on debian:latest rather than a fixed tag), and the site had to be served out of the content directory rather than the publish one we were using. I'm going to address a couple things as follow ups. We still point people to IRC, I'll update that to slack. Longer term I'll migrate it to Hugo, which will make the entire process a lot easier. Jon On Wed, Oct 9, 2019 at 10:26 PM Jon Haddad wrote: > OK, I checked with INFRA on some details and will finish the migration > tomorrow. > > On Thu, Oct 3, 2019 at 11:32 AM Jon Haddad wrote: > >> Awesome, thanks Michael. >> >> We need to do a little bit of additional configuration to have it switch >> over. Specifically, we need to set up the .asf.yaml config to tell the >> servers how the site should be published. I can take care of it >> tomorrow. >> >> Reference: >> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Publishingabranchtoyourprojectwebsite >> >> On Thu, Oct 3, 2019 at 10:57 AM Michael Shuler >> wrote: >> >>> committed! :) >>> >>> https://gitbox.apache.org/repos/asf?p=cassandra-website.git >>> >>> Michael >>> >>> On 10/3/19 12:22 PM, Jon Haddad wrote: >>> > I think we can safely ignore them. Thanks for figuring this out. >>> > >>> > On Thu, Oct 3, 2019 at 10:01 AM Michael Shuler >> > >>> > wrote: >>> > >>> >> I'm making progress through many periodic timeouts to svn.a.o and >>> >> restarts, but it appears that svn2git is smart enough to pick up where >>> >> it left off. The first commit captured at the svn path I'm specifying >>> is >>> >> when Cassandra was moved to a top level project at r922689 >>> (2010-03-13). >>> >> I don't know the old incubator path, and it's probably OK to ignore >>> the >>> >> few older incubator commits? I imagine it would mean starting over the >>> >> entire import to pull in those older incubator svn commits, then >>> >> changing the url and somehow importing the newer path on top? >>> >> >>> >> I tried using a local path as the source to try to speed things up, >>> >> after I got my first few timeouts, but that fails. >>> >> >>> >> Curious if anyone really cares if we lose a few early commits - if >>> so, I >>> >> can try to figure out the old path and start again. >>> >> >>> >> Michael >>> >> >>> >> On 10/3/19 11:14 AM, Jon Haddad wrote: >>> >>> Thanks for taking a look, Michael. Hopefully you have better luck >>> than >>> >> me >>> >>> :) >>> >>> >>> >>> On Thu, Oct 3, 2019 at 6:42 AM Michael Shuler < >>> mich...@pbandjelly.org> >>> >>> wrote: >>> >>> >>> I cloned the empty cassandra-website git repo, and I'm running: >>> >>> svn2git http://svn.apache.org/repos/asf/cassandra/site >>> --rootistrunk >>> --no-minimize-url >>> >>> ..to see what I get. An svn checkout of the above url says it's only >>> 69M, so I suppose it's pulling all history of all time for all >>> projects? >>> >>> I'll let this roll for a while I run an errand and report back! >>> >>> Michael >>> >>> On 10/2/19 9:30 PM, Jon Haddad wrote: >>> > Daniel referred me to the GitBox self service system. >>> > >>> > I've attempted to port the site over using the tool Michael >>> suggested, >>> but >>> > after a couple hours it died with this message: >>> > >>> > command failed: r922600 >>> > git checkout -f master >>> > >>> > If either of you (Mick or Michael) want to give svn2git a shot >>> maybe >>> you'll >>> > get a different result.I think it may have been due to the >>> large >>> >> size >>> > of the repo and the small drive on the VM I was using. I can try >>> it >>> again >>> > tomorrow with more storage to see if I get a better result. Mick >>> if >>> >> you >>> > want to give it a shot in the meantime that would be appreciated. >>> > >>> > Jon >>> > >>> > On Wed, Oct 2, 2019 at 3:18 PM Jon Haddad >>> wrote: >>> > >>> >> I created an INFRA ticket here: >>> >> https://issues.apache.org/jira/browse/INFRA-19218. >>> >> >>> >> On Wed, Sep 25, 2019 at 6:04 AM Michael Shuler < >>> >> mich...@pbandjelly.org> >>> >> wrote: >>> >> >>> >>> I see no good reason to trash history. There are tools to make >>> moving >>> >>> from svn to git (hopefully) painless. We used git-svn for the >>> main c* >>> >>> source to retain history of both, which this tool uses to do >>> >> migrations >>> >>> - https://github.com/nirvdrum/svn2git >>> >>> >>> >>> Michael >>> >>> >>> >>> On 9/25/19 12:57 AM, Mick Semb Wever wrote: >>> >>> > Personally, no, I don't. What I need to know is if someone who >>> >>> actually >>> > works on the site needs the history in *git*. >>> >>> >>> Yes. I need the history in
Re: Improving our frequency of (patch) releases, and letting committers make releases
Might make sense to split the difference and have a loose reactive policy of "consider / discuss a potential release when any of the following are hit": 1. something critical is merged (data loss fix, cluster down fix, etc) 2. there are changes to the branch 3. it's been weeks since the last patch Maybe having triggers at reasonably fat M/N above (30/8?) would be enough to trigger those conversations and keep momentum on releases while respecting both the highly variable delta each change can have as well as our variable resources to commit to release validation across the project as contributors. On Thu, Oct 17, 2019 at 8:23 AM Jon Haddad wrote: > Mick's absolutely right. Even if we had been doing more frequent releases, > it's a big risk for us to only have one person able to it in the first > place. > > I also agree with Benedict. I don't think we need to be crazy strict about > windows. As long as we tell folks they may need to import keys, I think > we're much better off than we are now. > > On Thu, Oct 17, 2019 at 5:08 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > +1 > > > > We need to do something about this, and I don't mind what. It would be > > better if we cut fix releases immediately after a critical fix lands, > much > > as we used to. We've got fairly lazy about producing releases, perhaps > > because many of the full-time contributors now work for organisations > that > > don't really need them. > > > > We should definitely add any willing volunteers to the KEYS file now. I > > don't personally think we need any kind of a strict policy about > modifying > > it in future, except that if our release cadence drops and we have > willing > > volunteers we should do it again. > > > > > > On 17/10/2019, 07:50, "Mick Semb Wever" wrote: > > > > > > > We're still in the position where only four people in the project: > > > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > > > release. > > > > > > Our current patch release frequency is lacking. It's been 8 months > > since 3.11.4. > > This is having an impact on users and their faith in the technology. > > > > There is currently only one person in the community that is actively > > making releases. This really doesn't inspire confidence. We really should > > be cutting a patch release every 2 to 6 weeks, if critical fixes apply, > > imho. And I for one would certainly like to be helping out with this > > situation. > > > > If we choose to address this issue, there are two facets to it that > > come to mind: > > 1) This misnomer that committers can't cut and publish releases. > > 2) That we can't make changes to the KEYS file (or that it's too > > painful to do so). > > > > Re (1). I'm not sure where this misunderstanding came from in our > > community. But the ASF policy does not prevent committers from being the > > release manager. By default the only thing in the process a committer > can't > > do is publish the successfully voted upon release from stage to public. > > This is a one-line svn command and the last and very small action in the > > release process at large. A committer can coordinate, cut, stage, > announce, > > and initiate the vote on a release, which is the bulk of the work. And > the > > committer can also do the final publish command if the PMC has voted that > > this is ok in this community. This is all in > > http://www.apache.org/legal/release-policy.html > > > > > > > Is it time to add more people to our KEYS file? > > > This will have the consequence that debian users will have to > re-add > > it. > > > > > > Re (2), the problem is that changes to the KEYS file mean that debian > > users have to re-import it before pulling new packages. But is that > really > > worse than an 8 month or more for an earlier patch version like ".5" ? > > > > > > > But maybe we can accept a window, from now until the first 4.0 rc, > > > where all committers are free to open a PR to add themselves to the > > > KEYS file? > > > > > > I can think of a number of ways forward on this. > > a) remove the constraint that we can't update the KEYS file, asking > > debian users to be prepared to have to re-import it. > > b) open a one-off window where we get as many PMC and Committers as > > possible to add their gpg key to the KEYS file. > > c) open a regular window each year, eg last quarter, where we > > collect new keys to add from new PMC and Committers, and merge them all > in, > > in one go, at the end of that window. > > > > It would be great to be in a better place than the current situation > > where we have only four keys in the file :-( > > > > regards, > > Mick > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > >
Re: Improving our frequency of (patch) releases, and letting committers make releases
Mick's absolutely right. Even if we had been doing more frequent releases, it's a big risk for us to only have one person able to it in the first place. I also agree with Benedict. I don't think we need to be crazy strict about windows. As long as we tell folks they may need to import keys, I think we're much better off than we are now. On Thu, Oct 17, 2019 at 5:08 AM Benedict Elliott Smith wrote: > +1 > > We need to do something about this, and I don't mind what. It would be > better if we cut fix releases immediately after a critical fix lands, much > as we used to. We've got fairly lazy about producing releases, perhaps > because many of the full-time contributors now work for organisations that > don't really need them. > > We should definitely add any willing volunteers to the KEYS file now. I > don't personally think we need any kind of a strict policy about modifying > it in future, except that if our release cadence drops and we have willing > volunteers we should do it again. > > > On 17/10/2019, 07:50, "Mick Semb Wever" wrote: > > > > We're still in the position where only four people in the project: > > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > > release. > > > Our current patch release frequency is lacking. It's been 8 months > since 3.11.4. > This is having an impact on users and their faith in the technology. > > There is currently only one person in the community that is actively > making releases. This really doesn't inspire confidence. We really should > be cutting a patch release every 2 to 6 weeks, if critical fixes apply, > imho. And I for one would certainly like to be helping out with this > situation. > > If we choose to address this issue, there are two facets to it that > come to mind: > 1) This misnomer that committers can't cut and publish releases. > 2) That we can't make changes to the KEYS file (or that it's too > painful to do so). > > Re (1). I'm not sure where this misunderstanding came from in our > community. But the ASF policy does not prevent committers from being the > release manager. By default the only thing in the process a committer can't > do is publish the successfully voted upon release from stage to public. > This is a one-line svn command and the last and very small action in the > release process at large. A committer can coordinate, cut, stage, announce, > and initiate the vote on a release, which is the bulk of the work. And the > committer can also do the final publish command if the PMC has voted that > this is ok in this community. This is all in > http://www.apache.org/legal/release-policy.html > > > > Is it time to add more people to our KEYS file? > > This will have the consequence that debian users will have to re-add > it. > > > Re (2), the problem is that changes to the KEYS file mean that debian > users have to re-import it before pulling new packages. But is that really > worse than an 8 month or more for an earlier patch version like ".5" ? > > > > But maybe we can accept a window, from now until the first 4.0 rc, > > where all committers are free to open a PR to add themselves to the > > KEYS file? > > > I can think of a number of ways forward on this. > a) remove the constraint that we can't update the KEYS file, asking > debian users to be prepared to have to re-import it. > b) open a one-off window where we get as many PMC and Committers as > possible to add their gpg key to the KEYS file. > c) open a regular window each year, eg last quarter, where we > collect new keys to add from new PMC and Committers, and merge them all in, > in one go, at the end of that window. > > It would be great to be in a better place than the current situation > where we have only four keys in the file :-( > > regards, > Mick > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Improving our frequency of (patch) releases, and letting committers make releases
+1 We need to do something about this, and I don't mind what. It would be better if we cut fix releases immediately after a critical fix lands, much as we used to. We've got fairly lazy about producing releases, perhaps because many of the full-time contributors now work for organisations that don't really need them. We should definitely add any willing volunteers to the KEYS file now. I don't personally think we need any kind of a strict policy about modifying it in future, except that if our release cadence drops and we have willing volunteers we should do it again. On 17/10/2019, 07:50, "Mick Semb Wever" wrote: > We're still in the position where only four people in the project: > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > release. Our current patch release frequency is lacking. It's been 8 months since 3.11.4. This is having an impact on users and their faith in the technology. There is currently only one person in the community that is actively making releases. This really doesn't inspire confidence. We really should be cutting a patch release every 2 to 6 weeks, if critical fixes apply, imho. And I for one would certainly like to be helping out with this situation. If we choose to address this issue, there are two facets to it that come to mind: 1) This misnomer that committers can't cut and publish releases. 2) That we can't make changes to the KEYS file (or that it's too painful to do so). Re (1). I'm not sure where this misunderstanding came from in our community. But the ASF policy does not prevent committers from being the release manager. By default the only thing in the process a committer can't do is publish the successfully voted upon release from stage to public. This is a one-line svn command and the last and very small action in the release process at large. A committer can coordinate, cut, stage, announce, and initiate the vote on a release, which is the bulk of the work. And the committer can also do the final publish command if the PMC has voted that this is ok in this community. This is all in http://www.apache.org/legal/release-policy.html > Is it time to add more people to our KEYS file? > This will have the consequence that debian users will have to re-add it. Re (2), the problem is that changes to the KEYS file mean that debian users have to re-import it before pulling new packages. But is that really worse than an 8 month or more for an earlier patch version like ".5" ? > But maybe we can accept a window, from now until the first 4.0 rc, > where all committers are free to open a PR to add themselves to the > KEYS file? I can think of a number of ways forward on this. a) remove the constraint that we can't update the KEYS file, asking debian users to be prepared to have to re-import it. b) open a one-off window where we get as many PMC and Committers as possible to add their gpg key to the KEYS file. c) open a regular window each year, eg last quarter, where we collect new keys to add from new PMC and Committers, and merge them all in, in one go, at the end of that window. It would be great to be in a better place than the current situation where we have only four keys in the file :-( regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Improving our frequency of (patch) releases, and letting committers make releases
> We're still in the position where only four people in the project: > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > release. Our current patch release frequency is lacking. It's been 8 months since 3.11.4. This is having an impact on users and their faith in the technology. There is currently only one person in the community that is actively making releases. This really doesn't inspire confidence. We really should be cutting a patch release every 2 to 6 weeks, if critical fixes apply, imho. And I for one would certainly like to be helping out with this situation. If we choose to address this issue, there are two facets to it that come to mind: 1) This misnomer that committers can't cut and publish releases. 2) That we can't make changes to the KEYS file (or that it's too painful to do so). Re (1). I'm not sure where this misunderstanding came from in our community. But the ASF policy does not prevent committers from being the release manager. By default the only thing in the process a committer can't do is publish the successfully voted upon release from stage to public. This is a one-line svn command and the last and very small action in the release process at large. A committer can coordinate, cut, stage, announce, and initiate the vote on a release, which is the bulk of the work. And the committer can also do the final publish command if the PMC has voted that this is ok in this community. This is all in http://www.apache.org/legal/release-policy.html > Is it time to add more people to our KEYS file? > This will have the consequence that debian users will have to re-add it. Re (2), the problem is that changes to the KEYS file mean that debian users have to re-import it before pulling new packages. But is that really worse than an 8 month or more for an earlier patch version like ".5" ? > But maybe we can accept a window, from now until the first 4.0 rc, > where all committers are free to open a PR to add themselves to the > KEYS file? I can think of a number of ways forward on this. a) remove the constraint that we can't update the KEYS file, asking debian users to be prepared to have to re-import it. b) open a one-off window where we get as many PMC and Committers as possible to add their gpg key to the KEYS file. c) open a regular window each year, eg last quarter, where we collect new keys to add from new PMC and Committers, and merge them all in, in one go, at the end of that window. It would be great to be in a better place than the current situation where we have only four keys in the file :-( regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
