On Saturday 05 Nov 2011 20:35:00 David ?Bombe? Roden wrote: > Hi Matthew, > > > 1. The most valuable thing is probably not actually releasing builds. It's > > collecting patches and initial code review, integration into a tree (maybe > > master, maybe not), and *POSTING A TEST BUILD AND GETTING PEOPLE TO TEST > > IT*. > > Right. The only difference between release builds and test builds are that > users have to trigger updating to test builds themselves, correct?
Yes, and release builds can be mandatory. Also we could have many "streams" of test builds, by different developers, and thus let them release whatever they want to without it being officially endorsed, but the users still be able to use the update.sh <name> / update.cmd <name> conveniently. > > > Yes and no. Upgrading the network does have performance costs. These are > > much higher when it is a self-mandatory or soon-mandatory, which is why I > > have tried to avoid them where possible. I do think that a succession of > > builds can by itself significantly reduce performance over the short term. > > How many builds in how many days are we talking about? I don?t think we?ll be > facing an avalanche of test builds anyway. :) :) > > > I suggest that what is needed at this point is not actual final builds but > > test builds. > > I think we need both. Test builds are fine for the most cases but sometimes > we > do need release builds, such as updates for official plugins. Those should be > pushed sooner than later, I guess. True. Eventually we need real builds. Right now me, Ian and Nextgens could do a release (in some cases with significant effort). It may be that others should be added to that list. > > > - We need stuff merged into the main repository. Many people don't have > > access. Those who do can clobber the repository or rewrite its history > > (admittedly git makes recovery relatively easy), so need to be few in > > number. > > I do remember that in the beginning of the Git repository you were quite > liberal with access to the GitHub repository; I had to specifically ask you > to > remove my access because I felt that I shouldn?t have it without having any > official function back then. :) Yes, that was the (mistaken) policy at that point. > > So, yes, access to the GitHub repository should be restricted to people who > are allowed to release builds. Absolutely. > (Also, I think we should merge the *-official and > *-staging repositories because, frankly, that is what branches are for but > that is an entirely different issue.) > > I don?t think clobbering the main repository is an issue here. Access should > obviously not be given to everybody. :) > > > - Releasing binaries for the update scripts. > > I?m pretty sure that can be more or less automated. > > > - Updating the website. (This could be done by a trigger, requiring some > > scripting on osprey, or could be done directly). > > > - Deploying the auto-update jar. This must be signed, and is security > > critical for the entire network. > > Ditto. It's all automated, but it's a question of what level of automation is sufficiently secure. A build MUST be SIGNED by a specific developer, and his signing keys must be encrypted. So I don't think release-on-commit is a good idea. However there is a set of scripts that allows a developer to release a build reasonably easily - provided he has the secret keys and SSH access to freenetproject.org. > > > > This does, however, require that we keep the source code maintained in > > > the > > > repository a little bit tighter than we currently do. :) > > I'm not sure I follow your last comment. Certainly there is an argument for > > us having only a few committers to fred-staging. > > Yes but that is only part of it. Another part would be to use branches a bit > more strict, i.e. UI and plugin stuff is committed to a development branch, > and > client-layer, routing, crypto, the-hard-stuff etc. into one branch that?s for > you to review and merge back into the development branch when you?re done > with > it, and a master branch that the development branch is merged into when a > build is created (be it release or test). (?You? in this paragraph means ?you > personally or any person that is up to the task? so, basically, it means > ?you.? :) Big features should of course be on feature branches. Beyond that, it makes sense to have people who can build test-builds who can't actually do a release, and they should have their own repositories. > > Greetings, > > David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20111106/b3d0f449/attachment.pgp>
