[HTTPS-Everywhere] release schedule

[William Budington]

Hello Jonas,

Last month, I instituted a system by which ruleset maintainers are notified of a forthcoming release with a Github issue:

https://github.com/EFForg/https-everywhere/issues/4710

This is helpful for maintainers to finish up any work on pending rulesets or features that might be in the pipeline.

There is also a tag for this: "release-forthcoming," to easily group these type of issues.

Since this process has been instituted, a new milestone has been added to the project - "Before Next Release," to mark issues that are particularly pressing and should be resolved before the next release.

This process is a convenience, but it may not necessarily be followed - for example if there is a grave vulnerability and a release needs to be issued immediately.

A little while ago, we decided that our git workflow would be that anything merged into master is 'release-ready,' which is why we no longer have a branch specifically for features that are in pre-release stages.

As a general rule of thumb, if a ruleset is old enough that it was added to the bulk whitelist for validation checks, it's old enough to warrant a complete rewrite.  We could be more explicit about this rule of thumb.

The reason for not updating the rulesets over the air is because the rulesets themselves require as much of a signoff as the codebase itself, since any rule can transparently redirect a user to any arbitrary endpoint.  Because of this, we have to subject it to the same signing process.  At that point, might as well make a new release.  I'd love to get the release schedule to a couple of times a month.  Since taking over the project, the releases have been about once a month.

Hope this helps clarify things,
Bill Budington
Software Engineer
Electronic Frontier Foundation
https://www.eff.org/

On Tue, 07 Jun 2016 20:12:07 +0200, sjw at gmx.ch wrote:
> Hi
> 
> I would like to start a discussion about the current release schedule of
> HTTPS-Everywhere.
> 
> It seems that there is no official release management at the moment.
> There is actually no roadmap or milestones when a new version should be
> released. From time to time there is an update, but not regularly and
> without a separation between bugfixes and new features.
> There are also no such branches, like the Git workflow would recommend.
> 
> This makes it hard to add ruleset changes. It's not clear whether a rule
> should just be fixed or rewritten. Just fixing mostly result in failing
> tests, because the whole rule was written years ago.
> Sadly HTTPS-Everywhere can't update the rules without updating the whole
> extension. So if a rule get fixed it takes months before a new release
> ship this fix - together with a bunch of other changes and new features.
> 
> I think the reason for not updating the ruleset on the air is privacy in
> Tor. But could this be an optional feature for non-Tor browsers? This
> would also allow to beta test critical rules.
> There was also a discussion about spiting the repo in core and rulesets,
> but this has the drawback that commit logs get lost.
> 
> Can we define a future way how we handle those points to improve code
> health and transparency of HTTPS-Everywhere?
> 
> Regards,
> Jonas
> 




> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20160607/cbc65c7c/attachment.sig>