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 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.
> - 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. :)
So, yes, access to the GitHub repository should be restricted to people who
are allowed to release builds. (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).
Ditto.
> - Deploying the auto-update jar. This must be signed, and is security
> critical for the entire network.
Ditto.
> > 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.? :)
Greetings,
David
--
David ?Bombe? Roden <bombe at pterodactylus.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20111105/9ae30080/attachment.html>
-------------- 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/9ae30080/attachment.pgp>
