<p>I would *greatly* appreciate an answer to this question. Thank you.</p>
<p>---------- Forwarded message ----------<br>
From: "Russell Golden" <<a href="mailto:niveusluna@niveusluna.org">niveusluna@niveusluna.org</a>><br>
Date: Aug 23, 2012 8:23 AM<br>
Subject: Re: [HTTPS-Everywhere] 2.2.1 stable released<br>
To: "Peter Eckersley" <<a href="mailto:pde@eff.org">pde@eff.org</a>>, "<a href="mailto:https-everywhere@mail1.eff.org">https-everywhere@mail1.eff.org</a>" <<a href="mailto:https-everywhere@mail1.eff.org">https-everywhere@mail1.eff.org</a>><br>
</p>
<p>On Aug 18, 2012 12:34 AM, "Peter Eckersley" <<a href="mailto:pde@eff.org">pde@eff.org</a>> wrote:<br>
><br>
> As the package maintainer, it's up to you.  There have been a couple of times<br>
> in the history of the project when we've had to push releases quickly to deal<br>
> with breakage, so I can't promise it'll never happen again.  If appManaged<br>
> meant that Fedora/RHEL users wouldn't normally get HTTPS Everywhere updates<br>
> until they upgrade their OS, I'd say it was a bad idea because sites<br>
> themselves break their HTTPS support and we push updates to fix that.<br>
But if<br>
> appManaged means that you'll wait a few days after most stable releases before<br>
> pushing them to RedHat users, that seems fine.</p>
<p>It means they will have to update the RPM to receive updates, yes, but only if it doesn't already exist in their browser profile. If it does, then the system-wide version gets ignored completely, even if the system version is newer.</p>

<p>I absolutely plan to push updates to the repos within a few days of upstream release, absolutely.</p>
<p>The problem is that it is up to the user/sysadmin to update the RPMs, and some places have a stupid "what the heck are updates?" policy. They install the RHEL version that the makers of some product say they support, and never update it, ever. Makes me want to cry.</p>

<p>Now we come to the big question: what would you consider a timely update window? Without positive karma, Fedora updates require a minimum of 7 days in the testing repos before you can push them to stable. EPEL requires 14 days. I'm all for stability, but I think 14 days is a little ridiculous for a browser extension. Especially one that can break as readily as HTTPS Everywhere in ways beyond upstream's control. I do offer a side repo on <a href="http://repos.fedorapeople.org">repos.fedorapeople.org</a> for EPEL users that updates much faster, but I imagine that some sysadmins would be reluctant to use it.</p>

<p>Please send me your feedback on this question. I want stability for the package, but I don't want to leave users high and dry while the RPM sits in -testing waiting on karma, either. I'm still pretty new to packaging stuff, and I want all the feedback I can get.</p>

<p>Thank you.</p>