On 18 October 2016 at 13:25, Shane Curcuru <a...@shanecurcuru.org> wrote: > sebb wrote on 10/15/16 4:09 PM: >> There are quite a few PRs that have been outstanding for a while now. >> >> Apart from PR56, there has been no pushback, so I think it would be >> good to start applying them to master. >> >> Does anyone else want to do them? >> >> If not, any objections if I start doing so? > > Do we have a test suite, to ensure existing behavior isn't broken?
AFAICT there are no tests at all in the source repo. (That's also something I would like to help address) > Ponymail at the current time serves two communities: the ASF as a whole > for the live lists.a.o service, and the handful of outside parties who > currently run their own archives using ponymail code. So the key > question is for the short term: will your (unreviewed but no complaints) > PR likely break one of these clients in an un-obvious way, or in a way > that you wouldn't be able to help fix? I assume that lists.a.o will only deploy tested code. 3rd parties presumably have their own release processes which involve vetting changes. If not then they should understand the consequences. > From the ASF side, we'll detect issues quickly, so anything besides a > real privacy leak or a wrong data error is not that big a deal - just a > hassle for whoever gets to fix it. Personally, I'm all for making > progress on any non-architecture level code changes, so from the ASF > side, I'm happy for sebb to go ahead. > > Question: do outside users auto-deploy from master, or do they only pull > code when we declare a release or otherwise suggest it? Understanding > that would help us understand how careful we need to be with unreviewed > changes. The ASF release policy makes it very clear that only formal releases should be published to end users. So IMO the question of being careful with changes to trunk/master does not arise. Note that universal commit means that the Pony Mail podling cannot guarantee that accidental changes aren't made to the code. Even with code reviews, changes can be applied incorrectly, or out of sequence etc. That is partly why we vote on a frozen copy of the source, and releases are published in archives with hashes and sigs. Auto-deploy is an inherently risky strategy for code, especially code that can have irreversible effects (e.g. privacy leak). > - Shane > >
