[freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 17:19:13 schrieb David ?Bombe? Roden:
> On Friday 03 April 2009 14:14:41 Arne Babenhauserheide wrote:
> > $ hg sign [REVISION]
>
> git tag -s   -m 

Is that a GnuPG signed tag? 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- 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/20090403/d2684731/attachment.pgp>

[freenet-dev] git/hg hosting

[Florent Daigniere]

Daniel Cheng wrote:
> Florent Daigni?re wrote:
>> * Daniel Cheng  [2009-04-03 08:30:09]:
>>
>>> 2009/4/3 Florent Daigni?re :
 * Ian Clarke  [2009-04-02 17:44:37]:

> On Thu, Apr 2, 2009 at 1:55 PM, NextGen$  freenetproject.org>wrote:
>
>> Toad said on an other thread you wanted us to keep the same kind of
>> "workflow" : all the devs are pushing to the same repository... How does
>> what
>> you have written above integrate in the picture?
>>
>> Now I am confused.
>>
>> Do we want to lose the auto-build process? The bts integration, and other
>> related things? How do you want released to be rolled?
>>
> If we go with git and github they do support post-receive hooks:
>
> http://github.com/guides/post-receive-hooks
>
> I think the workflow can and should be very similar to what it is 
> currently,
> with developers pushing to a single authoritative repository.
>
 Okay, so it's technically possible (anyway, pulling on a regular basis
 was also an option)... but do we want to fetch code from a remote host
 we don't control and auto-run it on emu? The building process involves
 running the build-scripts.
>>> Currently, the svn commit protected by password.
>>> svn does not enforce signed https server cert,
>>> mitm attempts can harm as much as that.
>>>
>> Huh? Svn shows you the server's certificate fingerprint the first time
>> you use it... And we are using a valid SSL certificate signed by a 3rd
>> party.
> 
> You have never tell me the fingerprint, so it may have been hijacked
> since day 1.

No, that's why our certificates are signed by a 3rd party who's 
certificates ought to be known to you.

> And the password was sent to me using plain text...
> 

It shouldn't have been. If you sent me an encrypted email or your public 
key, I have used it.

Anyway, you can securely change it using 
https://emu.freenetproject.org/admin/

>>> Require for PGP signed commits, if you want something stronger.
>>>
>> Sure we can do that... but how integrated are the PGP/GPG modules with
>> git/hg? What about the GUI versions?
> 
> hg allow "hg sign" to sign a commits.
> git allow "git tag -s" to sign a tag.
> 
> One have to hack the pre-commit hook if we want
> to sign every commits.
> 
> The reasoning here is: every commit id is a hash.
> Once you sign a revision, you are quite sure it won't
> be changed.
> 
 NextGen$

 -BEGIN PGP SIGNATURE-
>>> [..]
 G3IAoIo???
>>> Your pgp signature is charset corrupted.
>> Hmm? I am not using UTF8; It's an ISO charset you might not have...
>>
> 
> PGP signature in mail should be 7-bit ASCII, right?
> 

No, I don't think so.

[freenet-dev] git/hg hosting

[David ‘Bombe’ Roden]

On Friday 03 April 2009 14:14:41 Arne Babenhauserheide wrote:

> $ hg sign [REVISION]

git tag -s   -m 

Built-in.


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/20090403/51a852b8/attachment.pgp>

[freenet-dev] [freenet-cvs] r26397 - trunk/freenet/src/freenet/client/async

[Daniel Cheng]

On Fri, Apr 3, 2009 at 7:59 AM,   wrote:
> Author: toad
> Date: 2009-04-02 23:59:42 + (Thu, 02 Apr 2009)
> New Revision: 26397
>
> Modified:
> ? trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
> Log:
> Better priority/retrycount comparison
>
>
> Modified: 
> trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
> ===
> --- trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java ? 
> ? ?2009-04-02 23:54:43 UTC (rev 26396)
> +++ trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java ? 
> ? ?2009-04-02 23:59:42 UTC (rev 26397)
> @@ -508,8 +508,10 @@
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Logger.minor(this, 
> "Ignoring cancelled recently succeeded item "+altReq);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?altReq = null;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(altReq != null && 
> altReq.getPriorityClass(container) <= choosenPriorityClass &&
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> fixRetryCount(altReq.getRetryCount()) <= chosenTracker.getNumber() && 
> !altReq.isEmpty(container) && altReq != req) {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int prio = 
> altReq.getPriorityClass(container);

altReq maybe null.
This is throwing NPE

> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? if(altReq != null &&

[freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 12:18:11 schrieb Florent Daigni?re:
> Sure we can do that... but how integrated are the PGP/GPG modules with
> git/hg? What about the GUI versions?

At least for hg you can just activate the gpg extension (distributed with hg) 
and can then sign changesets with 

$ hg sign [REVISION]

I didn't yet try to use TortoiseHG for signing. 

ctivate the extension by adding the following in .hg/hgrc (for one single 
repository) or ~/.hgrc (for the user)

[extensions]
hgext.gpg =


At least for Mercurial, more efficient than enforcing signatures for all 
commits would be to only allow a push, if all heads are signed or are 
signature commits coming after a signed commit, because that means that 
someone checked all new commits leading to the heads. 

Since Mercurial history is considered as mostly immutable (you need to 
activate history changing extensions to modify it, and you can't delete 
changes in others repositories - though you can revert them), this means that 
each set of changes will be checked before it gets into the main repo. 

This would also allow a workflow, where someone acts as gatekeeper and pulls 
contributions from others, which he/she then verifies, signs and pushes to the 
main repo. The contributions from others can for example be in anonymous 
repositories on freenet or can be sent by (free-)mail as patches. 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- 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/20090403/81d44315/attachment.pgp>

[freenet-dev] Provide Greater mobility to Freenet users via mobile phones.

[Juzer Arsiwala]

*Name:*Juzer Arsiwala
*Email: *jazz552 at gmail.com
*Project Title: *Greater Moblity to Freenet users.
*Benefits to the Freenet Community -* In todays world people do not have
much time they are always on the run. Hence it would be of great benefit if
we could provide them a way in which they could access their mails or reply
to them even when they are on the run.
  Besides emails the cost of calls are very high as oppose to calls
via the internet .Hence if we could provide them a way in which they could
call other mobile phones without paying those high cost then it will benefit
the community in a big way.

*Expected Results -*

* Provide the facility of viewing the email even without internet or gprs.
* Allowing the users to email through mobile phones.
* Advanced chat feature(Enhancement on the Freetalk feature) where people
can call other Freenet users through their mobile phones onto other peoples
mobile phones(Using voip concepts which will definitely be of great utility
to people).

*Project Schedule -* I believe that by working hard i can complete the
project within 3 months and fortunately i have a 3 month

long summer break.I can start on the project by the first week of may.
i am completely free this summer and i really want to make some contribution
to the open source community.

*I have the following project timeline in mind*

* Each of my first two goals which i have mentioned in the abstract will
take 45 days but i intend to continue even after the 3 month duration to
complete what i have started and provide the facility of calling at cheap
rates.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090403/580fea38/attachment.html>

[freenet-dev] [freenet-cvs] r26391 - trunk/freenet/test/freenet/client

[Daniel Cheng]

On Fri, Apr 3, 2009 at 6:30 AM,   wrote:
> Author: nextgens
> Date: 2009-04-02 22:30:59 + (Thu, 02 Apr 2009)
> New Revision: 26391
>
> Modified:
> ? trunk/freenet/test/freenet/client/CodeTest.java
> Log:
> Add a benchmark to the junit test; launch it with -Dbenchmark=true
> At the moment it produces weird results:
> ? ?[junit] Getting ready for benchmarking
> ? ?[junit] Native8Code[k=192,n=256]
> ? ?[junit] PureCode[k=192,n=256]
> ? ?[junit] Native code took 239ms whereas java's code took 76ms.

under my profiling:

1) The assertEquals is take more then 25% of time.
2) Randomize the array is taking around 7% of time
3) lots of time are spend on  new byte[]  / new Buffer.

after removing assertEquals and some byte array allocations:
: Native code took 40ms whereas java's code took 2ms.
: Native code took 3ms whereas java's code took 35ms.
: Native code took 4ms whereas java's code took 2ms.
: Native code took 29ms whereas java's code took 3ms.
: Native code took 3ms whereas java's code took 2ms.

These are more just random noises to me.

FYP, I am using the freenet-ext.jar from freenetproject.org.

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
Java HotSpot(TM) Client VM (build 1.5.0_17-b04, mixed mode, sharing)

Using the new libfec8.so give more or less the same result.
If you can reproduce this using other java version / cpu / arch,
maybe we should just drop the native library.

[freenet-dev] git/hg hosting

[Florent Daignière]

* Daniel Cheng <j16sdiz+freenet at gmail.com> [2009-04-03 08:30:09]:

> 2009/4/3 Florent Daigni?re :
> > * Ian Clarke  [2009-04-02 17:44:37]:
> >
> >> On Thu, Apr 2, 2009 at 1:55 PM, NextGen$  >> freenetproject.org>wrote:
> >>
> >> > Toad said on an other thread you wanted us to keep the same kind of
> >> > "workflow" : all the devs are pushing to the same repository... How does
> >> > what
> >> > you have written above integrate in the picture?
> >> >
> >> > Now I am confused.
> >> >
> >> > Do we want to lose the auto-build process? The bts integration, and other
> >> > related things? How do you want released to be rolled?
> >> >
> >>
> >> If we go with git and github they do support post-receive hooks:
> >>
> >> http://github.com/guides/post-receive-hooks
> >>
> >> I think the workflow can and should be very similar to what it is 
> >> currently,
> >> with developers pushing to a single authoritative repository.
> >>
> >
> > Okay, so it's technically possible (anyway, pulling on a regular basis
> > was also an option)... but do we want to fetch code from a remote host
> > we don't control and auto-run it on emu? The building process involves
> > running the build-scripts.
> 
> Currently, the svn commit protected by password.
> svn does not enforce signed https server cert,
> mitm attempts can harm as much as that.
> 

Huh? Svn shows you the server's certificate fingerprint the first time
you use it... And we are using a valid SSL certificate signed by a 3rd
party.

> Require for PGP signed commits, if you want something stronger.
> 

Sure we can do that... but how integrated are the PGP/GPG modules with
git/hg? What about the GUI versions?

> > NextGen$
> >
> > -BEGIN PGP SIGNATURE-
> [..]
> > G3IAoIo???
> 
> Your pgp signature is charset corrupted.

Hmm? I am not using UTF8; It's an ISO charset you might not have...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090403/d44abbba/attachment.pgp>

[freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 02:22:05 schrieb Daniel Cheng:
> DVCS does _NOT_ means accepting anonymous contribution.
>
> However, if we want to, there is nothing stopping us.

Personally I think it important for freenet to slowly establish a workflow 
where people contribute pseudonymously, because that will build a group of 
trusted committers which will be essential should freenet ever be outlawed. 

Also that will open the way to a seamless transition to completely freenet-
based development. 

For that workflow freenet needs to use a DVCS. 

> This is no different from what we have been doing.
> Lots of translation come from anonymous.
> And I have been committing under the name "Daniel Cheng",
> but nobody have ever verified my id.

But you can bet tracked down (you're posting in this ML...). 

I don't know what a copyright lawyer will say to completely anonymous 
contributions, so the VCS of Freenet should allow for pseudonymous management 
of the anonymous contributions. 

> > PS: For strengths and weaknesses of hg and git (and bzr), you can have a
> > look at the excellent DVCS PEP of Python. They analysed which DVCS would
> > be suited best for their different usecases:
> > - http://www.python.org/dev/peps/pep-0374/
>
> Hg is written in python.
> I have no question they can script Hg like me scripting Git..
> This is an extra advantage for them, but not us.
> [...]

Naturally hg being Python based is an extra advantage for Python - that's why 
I said "look at it", and not "follow their decision without thinking". 

They created a nice resource for projects switching from SVN. Every DVCSs part 
was written by a supporter of that DVCS. Logically the text has a bias towards 
Python, but since it's a Python PEP noone can claim he didn't know about that 
bias :) 

git in turn is written in C, bash and perl, which makes it harder to use for 
Windows users. 


What kind of scripts do you use? 

I ask, because as long as you don't do low-level index manipulation or similar 
plumbing stuff, you should be able to do the same with Mercurial - without 
using Python. 

Hooks for example are just shell commands defined in the repositories hgrc 
file (and can also call any kind of script). I use outgoing hooks to simply 
call lftp for uploading changed files when I do simple web development. 

Similarly the Mercurial shell interface (and its templating options) allow to 
easily use shell scripts for more highlevel tasks. 

Besides: I'll try to keep my posts focussed, because I already had one long 
git vs. hg discussion, and I assume you had yours, too - one initiation into 
the deep guts of DVCSs suffices :) 
Also I'm new to this list. 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- 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/20090403/b0192436/attachment.pgp>

[freenet-dev] git/hg hosting

[Ian Clarke]

On Thu, Apr 2, 2009 at 5:49 PM, Florent Daigni?re <
nextgens at freenetproject.org> wrote:

> Okay, so it's technically possible (anyway, pulling on a regular basis
> was also an option)... but do we want to fetch code from a remote host
> we don't control and auto-run it on emu? The building process involves
> running the build-scripts.


Well, we don't control emu either, its sitting in Bytemark's datacenter.
I'd say that github are at least as trustworthy as Bytemark.  I assume
scripts will be run in a walled-off user account, and we can take measures
to sandbox it - but it isn't like we are running the scripts after
downloading them from wikipedia.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090403/13517a7a/attachment.html>

[freenet-dev] [freenet-cvs] r26391 - trunk/freenet/test/freenet/client

[Ximin Luo]

Daniel Cheng wrote:
> On Fri, Apr 3, 2009 at 6:30 AM,   wrote:
>> Author: nextgens
>> Date: 2009-04-02 22:30:59 + (Thu, 02 Apr 2009)
>> New Revision: 26391
>>
>> Modified:
>>   trunk/freenet/test/freenet/client/CodeTest.java
>> Log:
>> Add a benchmark to the junit test; launch it with -Dbenchmark=true
>> At the moment it produces weird results:
>>[junit] Getting ready for benchmarking
>>[junit] Native8Code[k=192,n=256]
>>[junit] PureCode[k=192,n=256]
>>[junit] Native code took 239ms whereas java's code took 76ms.
> 
> under my profiling:
> 
> 1) The assertEquals is take more then 25% of time.
> 2) Randomize the array is taking around 7% of time
> 3) lots of time are spend on  new byte[]  / new Buffer.
> 
> after removing assertEquals and some byte array allocations:
> : Native code took 40ms whereas java's code took 2ms.
> : Native code took 3ms whereas java's code took 35ms.
> : Native code took 4ms whereas java's code took 2ms.
> : Native code took 29ms whereas java's code took 3ms.
> : Native code took 3ms whereas java's code took 2ms.
> 
> These are more just random noises to me.
> 
> FYP, I am using the freenet-ext.jar from freenetproject.org.
> 
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_17-b04, mixed mode, sharing)
> 
> Using the new libfec8.so give more or less the same result.
> If you can reproduce this using other java version / cpu / arch,
> maybe we should just drop the native library.
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

I get similar results; this is with svn-compiled freenet.jar *and* 
freenet-ext.jar

[junit] - Standard Output ---
[junit] Getting ready for benchmarking
[junit] Native8Code[k=192,n=256]
[junit] PureCode[k=192,n=256]
[junit] Native code took 200ms whereas java's code took 43ms.
[junit] -  ---

infinity0 at xl269:~/data0/projects/freenet/trunk/freenet$ uname -a
Linux xl269 2.6.26-1-amd64 #1 SMP Sat Jan 10 17:57:00 UTC 2009 x86_64 GNU/Linux

infinity0 at xl269:~/data0/projects/freenet/trunk/freenet$ java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5pre) (6b14-1.5~pre1-5)
OpenJDK 64-Bit Server VM (build 14.0-b10, mixed mode)

but for more accurate results we should write some longer tests, ie. ones which
take minutes, not milliseconds...

X

[freenet-dev] git/hg hosting

[Daniel Cheng]

2009/4/3 Florent Daigni?re :
> * Ian Clarke  [2009-04-02 17:44:37]:
>
>> On Thu, Apr 2, 2009 at 1:55 PM, NextGen$ > freenetproject.org>wrote:
>>
>> > Toad said on an other thread you wanted us to keep the same kind of
>> > "workflow" : all the devs are pushing to the same repository... How does
>> > what
>> > you have written above integrate in the picture?
>> >
>> > Now I am confused.
>> >
>> > Do we want to lose the auto-build process? The bts integration, and other
>> > related things? How do you want released to be rolled?
>> >
>>
>> If we go with git and github they do support post-receive hooks:
>>
>> http://github.com/guides/post-receive-hooks
>>
>> I think the workflow can and should be very similar to what it is currently,
>> with developers pushing to a single authoritative repository.
>>
>
> Okay, so it's technically possible (anyway, pulling on a regular basis
> was also an option)... but do we want to fetch code from a remote host
> we don't control and auto-run it on emu? The building process involves
> running the build-scripts.

Currently, the svn commit protected by password.
svn does not enforce signed https server cert,
mitm attempts can harm as much as that.

Require for PGP signed commits, if you want something stronger.

> NextGen$
>
> -BEGIN PGP SIGNATURE-
[..]
> G3IAoIo?

Your pgp signature is charset corrupted.

[freenet-dev] git/hg hosting

[Daniel Cheng]

2009/4/3 Arne Babenhauserheide :
> Am Freitag 03 April 2009 00:44:37 schrieb Ian Clarke:
>> If we go with git and github they do support post-receive hooks:
>>
>> http://github.com/guides/post-receive-hooks
>>
>> I think the workflow can and should be very similar to what it is
>> currently, with developers pushing to a single authoritative repository.
>
> The same is true for hg and bitbucket.org (though the corresponding Mercurial
> hook is "incoming").
>
> But both also offer far more possibilities.
>
>
> For example the question arises how to deal with pseudonymous contributions.
>
> If you take a psudonymous patch, how to take care of the copyright?

DVCS does _NOT_ means accepting anonymous contribution.

However, if we want to, there is nothing stopping us.

This is no different from what we have been doing.
Lots of translation come from anonymous.
And I have been committing under the name "Daniel Cheng",
but nobody have ever verified my id.

[...]

> PS: For strengths and weaknesses of hg and git (and bzr), you can have a look
> at the excellent DVCS PEP of Python. They analysed which DVCS would be suited
> best for their different usecases:
> - http://www.python.org/dev/peps/pep-0374/

Hg is written in python.
I have no question they can script Hg like me scripting Git..
This is an extra advantage for them, but not us.
[...]

[freenet-dev] ITA l10n update 090331

[Luke 771]

updated to latest trunk as of march 31 2009
I thought I sent it last tuesday but now I think I probably haven't
-- next part --
A non-text attachment was scrubbed...
Name: freenet.l10n.it.override.properties_luke771_090331
Type: application/octet-stream
Size: 1619 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090403/fea0c629/attachment.obj>

[freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 00:44:37 schrieb Ian Clarke:
> If we go with git and github they do support post-receive hooks:
>
> http://github.com/guides/post-receive-hooks
>
> I think the workflow can and should be very similar to what it is
> currently, with developers pushing to a single authoritative repository.

The same is true for hg and bitbucket.org (though the corresponding Mercurial 
hook is "incoming"). 

But both also offer far more possibilities. 


For example the question arises how to deal with pseudonymous contributions. 

If you take a psudonymous patch, how to take care of the copyright? 

Does freenet then need an anonymous repository where someone assembles an 
anonymous version which includes the patches of dubious legality? And who will 
trust that version? 


I can't help much with git (I gave up on it after it bit me once too often), 
but if you have questions about hg, I should be able to answer them - or at 
least find someone who is :)


Besides: Hi, I'm ArneBab from IRC, freenet user for more than 5 years, almost 
24/7 since I switched to GNU/Linux, and avid Mercurial user for a year, now :) 

PS: For strengths and weaknesses of hg and git (and bzr), you can have a look 
at the excellent DVCS PEP of Python. They analysed which DVCS would be suited 
best for their different usecases: 
- http://www.python.org/dev/peps/pep-0374/

PPS: If I write anything which was already discussed, please nudge me. I only 
skimmed part of the archives. 
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- 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/20090403/cbb7f928/attachment.pgp>

[freenet-dev] Load management / token passing / tit for tat was Re: The Free Network Project Summer Projects 2009

[David Cabanillas]

>Yes. Simulations of load management would be very welcome. You should
investigate the existing simulators (particularly the event-based ones),
which are in the SVN repository, I am hopeful that they can be adapted
without massive effort. You will need to more or less reproduce the current
load management system (AIMDs on the originator based on timeouts and
rejections, plus backoff to deal with individual slow peers, documented on
the wiki), and then simulate various proposals from the mailing lists for
new
systems.

Reviewing the SN repository I found
http://freenet.googlecode.com/svn/trunk/apps/load-balancing-sims/ from
phase1<http://freenet.googlecode.com/svn/trunk/apps/load-balancing-sims/phase1/>to
phase7. Are you talking about this simulations?


   - Simulations from phase1 to phase4 are only working with 3 nodes. In 6
   and 7 at least they are working with 100 nodes.
   - The simulation 4 introduces the AIMD algorithm (Peer.java).
   - In any simulation I have observed backoff process but we can consider
   that backoff is useful or it is necessary to assure by means of simulations
   that it is useful.


The proposals for extend the simulations are as follows:

   - To extend the simulations phases in large scale.
   - To compare simulations using and not using backoff.
   - To apply peer-peer token buckets to track fairness between accepting
   requests from different peers,
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090403/13aff0dd/attachment.html>

[freenet-dev] git/hg hosting

[Florent Daignière]

* Ian Clarke  [2009-04-02 17:44:37]:

> On Thu, Apr 2, 2009 at 1:55 PM, NextGen$  freenetproject.org>wrote:
> 
> > Toad said on an other thread you wanted us to keep the same kind of
> > "workflow" : all the devs are pushing to the same repository... How does
> > what
> > you have written above integrate in the picture?
> >
> > Now I am confused.
> >
> > Do we want to lose the auto-build process? The bts integration, and other
> > related things? How do you want released to be rolled?
> >
> 
> If we go with git and github they do support post-receive hooks:
> 
> http://github.com/guides/post-receive-hooks
> 
> I think the workflow can and should be very similar to what it is currently,
> with developers pushing to a single authoritative repository.
> 

Okay, so it's technically possible (anyway, pulling on a regular basis
was also an option)... but do we want to fetch code from a remote host
we don't control and auto-run it on emu? The building process involves
running the build-scripts.

NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: 

Re: [freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 02:22:05 schrieb Daniel Cheng:
 DVCS does _NOT_ means accepting anonymous contribution.

 However, if we want to, there is nothing stopping us.

Personally I think it important for freenet to slowly establish a workflow 
where people contribute pseudonymously, because that will build a group of 
trusted committers which will be essential should freenet ever be outlawed. 

Also that will open the way to a seamless transition to completely freenet-
based development. 

For that workflow freenet needs to use a DVCS. 

 This is no different from what we have been doing.
 Lots of translation come from anonymous.
 And I have been committing under the name Daniel Cheng,
 but nobody have ever verified my id.

But you can bet tracked down (you're posting in this ML...). 

I don't know what a copyright lawyer will say to completely anonymous 
contributions, so the VCS of Freenet should allow for pseudonymous management 
of the anonymous contributions. 

  PS: For strengths and weaknesses of hg and git (and bzr), you can have a
  look at the excellent DVCS PEP of Python. They analysed which DVCS would
  be suited best for their different usecases:
  - http://www.python.org/dev/peps/pep-0374/

 Hg is written in python.
 I have no question they can script Hg like me scripting Git..
 This is an extra advantage for them, but not us.
 [...]

Naturally hg being Python based is an extra advantage for Python - that's why 
I said look at it, and not follow their decision without thinking. 

They created a nice resource for projects switching from SVN. Every DVCSs part 
was written by a supporter of that DVCS. Logically the text has a bias towards 
Python, but since it's a Python PEP noone can claim he didn't know about that 
bias :) 

git in turn is written in C, bash and perl, which makes it harder to use for 
Windows users. 


What kind of scripts do you use? 

I ask, because as long as you don't do low-level index manipulation or similar 
plumbing stuff, you should be able to do the same with Mercurial - without 
using Python. 

Hooks for example are just shell commands defined in the repositories hgrc 
file (and can also call any kind of script). I use outgoing hooks to simply 
call lftp for uploading changed files when I do simple web development. 

Similarly the Mercurial shell interface (and its templating options) allow to 
easily use shell scripts for more highlevel tasks. 

Besides: I'll try to keep my posts focussed, because I already had one long 
git vs. hg discussion, and I assume you had yours, too - one initiation into 
the deep guts of DVCSs suffices :) 
Also I'm new to this list. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] [freenet-cvs] r26397 - trunk/freenet/src/freenet/client/async

[Daniel Cheng]

On Fri, Apr 3, 2009 at 7:59 AM,  t...@freenetproject.org wrote:
 Author: toad
 Date: 2009-04-02 23:59:42 + (Thu, 02 Apr 2009)
 New Revision: 26397

 Modified:
   trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
 Log:
 Better priority/retrycount comparison


 Modified: 
 trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
 ===
 --- trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java    
   2009-04-02 23:54:43 UTC (rev 26396)
 +++ trunk/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java    
   2009-04-02 23:59:42 UTC (rev 26397)
 @@ -508,8 +508,10 @@
                                                        Logger.minor(this, 
 Ignoring cancelled recently succeeded item +altReq);
                                                altReq = null;
                                        }
 -                                       if(altReq != null  
 altReq.getPriorityClass(container) = choosenPriorityClass 
 -                                                       
 fixRetryCount(altReq.getRetryCount()) = chosenTracker.getNumber()  
 !altReq.isEmpty(container)  altReq != req) {
 +                                       int prio = 
 altReq.getPriorityClass(container);

altReq maybe null.
This is throwing NPE

 +                                       if(altReq != null 
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Florent Daignière]

* Daniel Cheng j16sdiz+free...@gmail.com [2009-04-03 08:30:09]:

 2009/4/3 Florent Daignière nextg...@freenetproject.org:
  * Ian Clarke i...@locut.us [2009-04-02 17:44:37]:
 
  On Thu, Apr 2, 2009 at 1:55 PM, NextGen$ 
  nextg...@freenetproject.orgwrote:
 
   Toad said on an other thread you wanted us to keep the same kind of
   workflow : all the devs are pushing to the same repository... How does
   what
   you have written above integrate in the picture?
  
   Now I am confused.
  
   Do we want to lose the auto-build process? The bts integration, and other
   related things? How do you want released to be rolled?
  
 
  If we go with git and github they do support post-receive hooks:
 
  http://github.com/guides/post-receive-hooks
 
  I think the workflow can and should be very similar to what it is 
  currently,
  with developers pushing to a single authoritative repository.
 
 
  Okay, so it's technically possible (anyway, pulling on a regular basis
  was also an option)... but do we want to fetch code from a remote host
  we don't control and auto-run it on emu? The building process involves
  running the build-scripts.
 
 Currently, the svn commit protected by password.
 svn does not enforce signed https server cert,
 mitm attempts can harm as much as that.
 

Huh? Svn shows you the server's certificate fingerprint the first time
you use it... And we are using a valid SSL certificate signed by a 3rd
party.

 Require for PGP signed commits, if you want something stronger.
 

Sure we can do that... but how integrated are the PGP/GPG modules with
git/hg? What about the GUI versions?

  NextGen$
 
  -BEGIN PGP SIGNATURE-
 [..]
  G3IAoIo???
 
 Your pgp signature is charset corrupted.

Hmm? I am not using UTF8; It's an ISO charset you might not have...


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 12:18:11 schrieb Florent Daignière:
 Sure we can do that... but how integrated are the PGP/GPG modules with
 git/hg? What about the GUI versions?

At least for hg you can just activate the gpg extension (distributed with hg) 
and can then sign changesets with 

$ hg sign [REVISION]

I didn't yet try to use TortoiseHG for signing. 

ctivate the extension by adding the following in .hg/hgrc (for one single 
repository) or ~/.hgrc (for the user)

[extensions]
hgext.gpg =


At least for Mercurial, more efficient than enforcing signatures for all 
commits would be to only allow a push, if all heads are signed or are 
signature commits coming after a signed commit, because that means that 
someone checked all new commits leading to the heads. 

Since Mercurial history is considered as mostly immutable (you need to 
activate history changing extensions to modify it, and you can't delete 
changes in others repositories - though you can revert them), this means that 
each set of changes will be checked before it gets into the main repo. 

This would also allow a workflow, where someone acts as gatekeeper and pulls 
contributions from others, which he/she then verifies, signs and pushes to the 
main repo. The contributions from others can for example be in anonymous 
repositories on freenet or can be sent by (free-)mail as patches. 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Ian Clarke]

On Thu, Apr 2, 2009 at 5:49 PM, Florent Daignière 
nextg...@freenetproject.org wrote:

 Okay, so it's technically possible (anyway, pulling on a regular basis
 was also an option)... but do we want to fetch code from a remote host
 we don't control and auto-run it on emu? The building process involves
 running the build-scripts.


Well, we don't control emu either, its sitting in Bytemark's datacenter.
I'd say that github are at least as trustworthy as Bytemark.  I assume
scripts will be run in a walled-off user account, and we can take measures
to sandbox it - but it isn't like we are running the scripts after
downloading them from wikipedia.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[David ‘Bombe’ Roden]

On Friday 03 April 2009 14:14:41 Arne Babenhauserheide wrote:

 $ hg sign [REVISION]

git tag -s name commit -m message

Built-in.


David


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Daniel Cheng]

Florent Daignière wrote:
 * Daniel Cheng j16sdiz+free...@gmail.com [2009-04-03 08:30:09]:
 
 2009/4/3 Florent Daignière nextg...@freenetproject.org:
 * Ian Clarke i...@locut.us [2009-04-02 17:44:37]:

 On Thu, Apr 2, 2009 at 1:55 PM, NextGen$ 
 nextg...@freenetproject.orgwrote:

 Toad said on an other thread you wanted us to keep the same kind of
 workflow : all the devs are pushing to the same repository... How does
 what
 you have written above integrate in the picture?

 Now I am confused.

 Do we want to lose the auto-build process? The bts integration, and other
 related things? How do you want released to be rolled?

 If we go with git and github they do support post-receive hooks:

 http://github.com/guides/post-receive-hooks

 I think the workflow can and should be very similar to what it is 
 currently,
 with developers pushing to a single authoritative repository.

 Okay, so it's technically possible (anyway, pulling on a regular basis
 was also an option)... but do we want to fetch code from a remote host
 we don't control and auto-run it on emu? The building process involves
 running the build-scripts.
 Currently, the svn commit protected by password.
 svn does not enforce signed https server cert,
 mitm attempts can harm as much as that.

 
 Huh? Svn shows you the server's certificate fingerprint the first time
 you use it... And we are using a valid SSL certificate signed by a 3rd
 party.

You have never tell me the fingerprint, so it may have been hijacked
since day 1. And the password was sent to me using plain text...

 Require for PGP signed commits, if you want something stronger.

 
 Sure we can do that... but how integrated are the PGP/GPG modules with
 git/hg? What about the GUI versions?

hg allow hg sign to sign a commits.
git allow git tag -s to sign a tag.

One have to hack the pre-commit hook if we want
to sign every commits.

The reasoning here is: every commit id is a hash.
Once you sign a revision, you are quite sure it won't
be changed.

 NextGen$

 -BEGIN PGP SIGNATURE-
 [..]
 G3IAoIo???
 Your pgp signature is charset corrupted.
 
 Hmm? I am not using UTF8; It's an ISO charset you might not have...
 

PGP signature in mail should be 7-bit ASCII, right?


___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Florent Daigniere]

Daniel Cheng wrote:
 Florent Daignière wrote:
 * Daniel Cheng j16sdiz+free...@gmail.com [2009-04-03 08:30:09]:

 2009/4/3 Florent Daignière nextg...@freenetproject.org:
 * Ian Clarke i...@locut.us [2009-04-02 17:44:37]:

 On Thu, Apr 2, 2009 at 1:55 PM, NextGen$ 
 nextg...@freenetproject.orgwrote:

 Toad said on an other thread you wanted us to keep the same kind of
 workflow : all the devs are pushing to the same repository... How does
 what
 you have written above integrate in the picture?

 Now I am confused.

 Do we want to lose the auto-build process? The bts integration, and other
 related things? How do you want released to be rolled?

 If we go with git and github they do support post-receive hooks:

 http://github.com/guides/post-receive-hooks

 I think the workflow can and should be very similar to what it is 
 currently,
 with developers pushing to a single authoritative repository.

 Okay, so it's technically possible (anyway, pulling on a regular basis
 was also an option)... but do we want to fetch code from a remote host
 we don't control and auto-run it on emu? The building process involves
 running the build-scripts.
 Currently, the svn commit protected by password.
 svn does not enforce signed https server cert,
 mitm attempts can harm as much as that.

 Huh? Svn shows you the server's certificate fingerprint the first time
 you use it... And we are using a valid SSL certificate signed by a 3rd
 party.
 
 You have never tell me the fingerprint, so it may have been hijacked
 since day 1.

No, that's why our certificates are signed by a 3rd party who's 
certificates ought to be known to you.

 And the password was sent to me using plain text...
 

It shouldn't have been. If you sent me an encrypted email or your public 
key, I have used it.

Anyway, you can securely change it using 
https://emu.freenetproject.org/admin/

 Require for PGP signed commits, if you want something stronger.

 Sure we can do that... but how integrated are the PGP/GPG modules with
 git/hg? What about the GUI versions?
 
 hg allow hg sign to sign a commits.
 git allow git tag -s to sign a tag.
 
 One have to hack the pre-commit hook if we want
 to sign every commits.
 
 The reasoning here is: every commit id is a hash.
 Once you sign a revision, you are quite sure it won't
 be changed.
 
 NextGen$

 -BEGIN PGP SIGNATURE-
 [..]
 G3IAoIo???
 Your pgp signature is charset corrupted.
 Hmm? I am not using UTF8; It's an ISO charset you might not have...

 
 PGP signature in mail should be 7-bit ASCII, right?
 

No, I don't think so.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Freitag 03 April 2009 17:19:13 schrieb David ‘Bombe’ Roden:
 On Friday 03 April 2009 14:14:41 Arne Babenhauserheide wrote:
  $ hg sign [REVISION]

 git tag -s name commit -m message

Is that a GnuPG signed tag? 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Daniel Cheng]

2009/4/4 Arne Babenhauserheide arne_...@web.de:
 Am Freitag 03 April 2009 17:19:13 schrieb David ‘Bombe’ Roden:
 On Friday 03 April 2009 14:14:41 Arne Babenhauserheide wrote:
  $ hg sign [REVISION]

 git tag -s name commit -m message

 Is that a GnuPG signed tag?

-s is sign

 Best wishes,
 Arne
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[David ‘Bombe’ Roden]

On Friday 03 April 2009 18:29:04 Arne Babenhauserheide wrote:

   $ hg sign [REVISION]
  git tag -s name commit -m message
 Is that a GnuPG signed tag?

Yes. Check [1] for an example.


David

[1]: 
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=tag;h=5dfd736f95b3d84a18b5bb8e50ac71f245438acf


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl