On Monday 27 April 2009 14:14:40 Daniel Cheng wrote: > 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".
Exactly. This is a secure workflow. Sending diffs to the list and reviewing them there is not. > > > > And don't forget the CIA.vc bot -- I guess it have no security impact, right? Agreed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090427/2aaeb342/attachment.pgp>
