Okay, my additional thoughts since last time first: 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*. This can be done by releasing an official pre- build but it could also be done by simply uploading a jar. Other projects with centralised DSCM-based workflows do something similar, e.g. the kernel.
2. We need a new list maintainer. We can dump everything posted to devl, tech etc from non-subscribers to /dev/null but often important bug reports on support@ come from people who are not on the list. So we need a volunteer for this too. 3. Maintenance of osprey. Who is responsible for this at the moment? I think several people have volunteered in the past? So we need multiple volunteers. It should be possible to provide official hosting for semi-official test builds by different people, and make the update scripts work for multiple sources. On Friday 04 Nov 2011 20:22:14 David ?Bombe? Roden wrote: > Hi Matthew, > > > The other side of this is not having lots of builds close together improves > > stability and therefore performance. > > The only thing causing disruptions are changes in routing and inter-node > communication but those builds will generally not talk to older nodes anyway, > right? 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. > > Your expertise in maintaining the very core of Freenet is invaluable. On > short > notice nobody can take over your job so the decision about routing-relevant > merges, i.e. anything that touches old/new last good build, would still > reside > in your hands; maybe in a separate branch that you merge into the main > development branch every now and then after you?ve reviewed other people?s > commits or wrote some yourself. The main development branch could hold the > more cosmetic stuff or changes that will not affect the network as a whole; > those changes can be reviewed by somebody with less knowledge about Freenet?s > intestines. Also, new builds containing only those changes could be released > with little chance of disrupting the network. I suggest that what is needed at this point is not actual final builds but test builds. When we do want to have multiple people releasing final builds, there are several issues: - 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. - Releasing binaries for the update scripts. - 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. > 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. > > > 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/20111105/ae154a85/attachment.pgp>
