On Mon, Apr 27, 2009 at 9:02 PM, Daniel Cheng <j16sdiz+freenet at gmail.com>
wrote:
> On Mon, Apr 27, 2009 at 8:10 PM, Matthew Toseland
> <toad at amphibian.dyndns.org> wrote:
>> On Sunday 26 April 2009 01:14:34 Daniel Cheng wrote:
>>> On Sun, Apr 26, 2009 at 12:03 AM, Matthew Toseland
>>> <toad at amphibian.dyndns.org> wrote:
>>> > On Saturday 25 April 2009 04:13:39 Matthew Toseland wrote:
>>> >> The SVN repository is read-only, and I have taken a dump. It will be
>> posted
>>> > to
>>> >> Freenet soon and I will announce the location of the file, the gpg
>> signature
>>> >> etc. We might also put it on the mirrors network, but it is 281MB, so I
>>> > dunno
>>> >> if this is a good idea. In the meantime, the SHA256 checksum is:
>>> >> 5417c7f26fc5baeb9fa2186194f70f00d2470d924a98c03f21561c4020f32538
>>> >>
>>> >> We are using github, and on nextgens suggestion (and partly due to
>> security
>>> >> issues with github) we will have for each sub-project two trees:
>>> >> - The official tree. This is code which has been reviewed by a trusted
>>> >> developer.
>>> >> - The staging tree. All developers - just about anyone who asks for an
>>> >> account - will have push access to this tree.
>>> >>
>>> >> Of course I will also take pull requests from devs who have their own
>> trees.
>>> >> Please post on devl if you think your tree is ready to be pulled; and if
>> you
>>> >> don't, it would be great to know about work in progress.
>>> >>
>>> >> IMHO the cost of the above arrangement is marginal: code has to be
>> reviewed
>>> >> anyway before we release it, and pushing it to the official tree does not
>>> >> cost significant time. Testing builds can either be created as part of
>> this
>>> >> process or can be auto-built from the known safe official tree.
>>> >>
>>> >> Stable builds of freenet itself will be released from the official tree
>>> > after
>>> >> creating a tag. I will build them locally, sign the tag and the source
>> code
>>> >> tarball, and upload them both to the web and to the Freenet auto-updater.
>>> >> IMHO this is the right arrangement for code run on newbie nodes,
>> including
>>> >> for plugins, but especially for anything inserted into the
>>> >> auto-update-over-Freenet system.
>>> >>
>>> >> If you want access to the staging tree, please create an account on
>> github
>>> > and
>>> >> email me the username. Sign your mail if possible.
>>> >>
>>> >> The github page, with a list of all sub-projects:
>>> >> http://github.com/freenet/
>>> >>
>>> >> Notable sub-projects:
>>> >>
>>> >> fred (the Freenet daemon itself)
>>> >>
>>> >> git://github.com/freenet/fred-official.git
>>> >> git://github.com/freenet/fred-staging.git
>>> >>
>>> >> contrib (freenet-ext.jar, currently doesn't include wrapper source)
>>> >>
>>> >> git://github.com/freenet/contrib-official.git
>>> >> git://github.com/freenet/contrib-staging.git
>>> >>
>>> >> new_installer (the installer)
>>> >>
>>> >> git://github.com/freenet/java_installer-staging.git
>>> >> git://github.com/freenet/java_installer-official.git
>>> >>
>>> >> wininstaller (Zero3's new windows-only installer)
>>> >>
>>> >> git://github.com/freenet/wininstaller-staging.git
>>> >> git://github.com/freenet/wininstaller-official.git
>>> >>
>>> >> Freetalk
>>> >>
>>> >> git://github.com/freenet/plugin-Freetalk-staging.git
>>> >> git://github.com/freenet/plugin-Freetalk-official.git
>>> >>
>>> >> And so on.
>>> >>
>>> >> I will sort out the rest soon, I have imported the most important stuff,
>> the
>>> >> rest should not take long. I will also sort out new scripts for building
>>> >> stable builds etc.
>>> >
>>> > I have completed the conversion of the repositories. Some projects
>>> > have -official and -staging and some do not. Specifically, anything which
>> is
>>> > bundled with Freenet, including all non-obsolete official plugins,
>>> > have -official and -staging. Some libraries do. Old stuff, simulators,
>>> > applications that we don't bundle etc, generally don't.
>>> >
>>> > Note that there are two possible URLs for each subproject, for example:
>>> >
>>> > Public: git://github.com/freenet/Thaw.git
>>> > Private: git at github.com:freenet/Thaw.git
>>> >
>>> > Use the latter if you have write access, use the former if you're just
>> going
>>> > to clone and then ask somebody to pull.
>>> >
>>> > Most remaining work relates to building stuff and code review.
>>> >
>>> > Most plugins do not have individual build.xml's, they should, so that devs
>> can
>>> > build the jar and test it locally.
>>> >
>>> > There will not be any auto-build, at least for the time being, whether on
>> fred
>>> > or on plugins.
>>> >
>>>
>>> Please enable the email / cia bot thing, you can find the setting under
>>> https://github.com/freenet/<project name>/edit/hooks
>>
>> I am skeptical about diffs by email. Code should be reviewed directly from
>> the
>> repository, diffs by email is insecure.
>>
>
> On security -- I would agree with you.
>
> But email is easier for casual reviewing / issue tracking .
> We are in different timezones, we need some way to comment on code
> when there are disagreement / something unclear. Email is the method
> we used to.
Maybe I should explain how the linux kernel community / official git
reposity handle this.
There are two kind of developer -- "subsystem maintainer" and "casual
developers".
<subsystem maintainer case>
Subsystem maintainer would develop on his own branch.
When his code is ready, he will tag it and ask for a pull.
The main developer would then do a:
git branch -b
git fetch git://<subsystem maintainer's repo>/xxx.git histag
git log -p HEAD..histag
if he think the tree is fine, he would do a:
git merge histag
<casual developer case>
Casual developer would send his patch using email:
git send-email --annotate --to 'email at exmaple.com' -s
original/master..HEAD
The main developer would review them from email. If It's fine, he will
apply them
cat mbox-file | git am
Git would record the "From" line of the email as "author" and the main developer
as "committer".
>
> And don't forget the CIA.vc bot -- I guess it have no security impact, right?
> --
>
