[prev in list] [next in list] [prev in thread] [next in thread] 

List:       https-everywhere
Subject:    Re: [HTTPS-Everywhere] release schedule
From:       William Budington <bill () eff ! org>
Date:       2016-06-07 22:19:39
Message-ID: 20160607221939.GF29590 () X1
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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@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@lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere


["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

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

[prev in list] [next in list] [prev in thread] [next in thread]