[freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Dienstag 07 April 2009 10:28:30 schrieb Daniel Cheng:
> >> > > git tag -s   -m 
> > Can you also sign a revision without tagging it?
>
> No.
> In DVCS model, signing single revision does not make sense
>  -- since you will merge / rebase that revision as soon as it is merged.

I think it does make sense as long as you don't rewrite history. 

Every signed revision is a certified step on the way, but the signature is 
only relevant to automatic verification tools, not to users - except where a 
tag gets signed and the users want to be sure by whom the tag was created. 

Signed tags for each verified revision create quite much unnecessary noise. 

But since the decision is now set, that freenet will switch to git and lose 
history (ouch!), someone else will have to write the verification framework. 

Doing it in Mercurial is quite simple (I sketched one in my analog notebook 
while in on sunday), but I know far too little about git to try to do 
something similar there. 

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: 

Re: [freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Dienstag 07 April 2009 10:28:30 schrieb Daniel Cheng:
git tag -s name commit -m message
  Can you also sign a revision without tagging it?

 No.
 In DVCS model, signing single revision does not make sense
  -- since you will merge / rebase that revision as soon as it is merged.

I think it does make sense as long as you don't rewrite history. 

Every signed revision is a certified step on the way, but the signature is 
only relevant to automatic verification tools, not to users - except where a 
tag gets signed and the users want to be sure by whom the tag was created. 

Signed tags for each verified revision create quite much unnecessary noise. 

But since the decision is now set, that freenet will switch to git and lose 
history (ouch!), someone else will have to write the verification framework. 

Doing it in Mercurial is quite simple (I sketched one in my analog notebook 
while in on sunday), but I know far too little about git to try to do 
something similar there. 

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

[freenet-dev] git/hg hosting

[Matthew Toseland]

On Tuesday 07 April 2009 09:24:10 Arne Babenhauserheide wrote:
> Am Samstag 04 April 2009 22:50:11 schrieb Matthew Toseland:
> > Agreed, however we need to be careful as we can be sued for any 
> code which is copyrighted by somebody else; if we can provide the 
> would-be litigant with the identity of the committer, we don't have 
> this problem.
> 
> Sure. 
> 
> That's why someone needs to maintain a frenet-only pseudonymous 
> version of the repository where all pseudonymous contributions can 
> be gathered. :) 

:)
> 
> That pseudonymous version can then contain additional features, so 
> users have a rason for switching to it. 
> 
> We just need to find a way to make sure that this pseudonymous 
> repository doesn't get compromised. 

Well, that disqualifies me - I'm traceable.
> 
> 
> I think it would be nice to do this as repository which can be updated 
> only if at least 60% of a specific group of people agree. 

Why is that beneficial relative to a fully distributed model of people pulling 
if they like a patch?
> 
> Ideally with also the option of adding new people to the group if 
> enough people agree? 
> 
> Example: Assume that we have 5 trusted maintainers. If one of them 
> now wants to push some changes to the reference repository, at 
> least two others have to agree to get the new revision into freenet. 
> 
> If another maintainer joins the group, they need 4 people for pushing 
> code online, and if two leave the group, two people suffice. (joining 
> and leaving would need to be done as greoup decision - needs 3 of 5 
> for example). 

Such a mechanism will be necessary for trusted freesites in general - the 
reason we don't have an official freesite is what happens when the private 
key is compromised? The most basic scheme is to have a single revocation key, 
which if found indicates the key has been compromised, which can be inserted 
by trusted people. But it would be much better if each trusted person could 
have his own revocation key, and they could vote on adding new trusted 
people / kicking them out, and on recovery from a compromise of the main key.
> 
> It would be possible to implement this check decentrally: Each head 
> must be signed by a majority of the keys which are saved in freenet 
> to be accepted locally, else the foreign repository will be marked as 
> compromised. 
> 
> If the list of trusted keys is part of the repository, it will be possible 
to 
> update them. 
> 
> Ideally there should also be a mechanism for backup locations and 
> changing them. For example this could be done by having a list of 
> them in the repository. When the main repository gets 
> compromised, freenet should check the backups for updates. 
> 
> Adding in a few safety checks (always need backup locations and a 
> minimum number of maintainers), this looks to me like it should 
> work. 
> 
> Are there any weeknesses in this scheme (except the possibility that 
> the majority of maintainers overlooks some bad code)? 

Dunno...
> 
> Best wishes, 
> Arne
-- 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: 

Re: [freenet-dev] git/hg hosting

[Matthew Toseland]

On Tuesday 07 April 2009 09:24:10 Arne Babenhauserheide wrote:
 Am Samstag 04 April 2009 22:50:11 schrieb Matthew Toseland:
  Agreed, however we need to be careful as we can be sued for any 
 code which is copyrighted by somebody else; if we can provide the 
 would-be litigant with the identity of the committer, we don't have 
 this problem.
 
 Sure. 
 
 That's why someone needs to maintain a frenet-only pseudonymous 
 version of the repository where all pseudonymous contributions can 
 be gathered. :) 

:)
 
 That pseudonymous version can then contain additional features, so 
 users have a rason for switching to it. 
 
 We just need to find a way to make sure that this pseudonymous 
 repository doesn't get compromised. 

Well, that disqualifies me - I'm traceable.
 
 
 I think it would be nice to do this as repository which can be updated 
 only if at least 60% of a specific group of people agree. 

Why is that beneficial relative to a fully distributed model of people pulling 
if they like a patch?
 
 Ideally with also the option of adding new people to the group if 
 enough people agree? 
 
 Example: Assume that we have 5 trusted maintainers. If one of them 
 now wants to push some changes to the reference repository, at 
 least two others have to agree to get the new revision into freenet. 
 
 If another maintainer joins the group, they need 4 people for pushing 
 code online, and if two leave the group, two people suffice. (joining 
 and leaving would need to be done as greoup decision - needs 3 of 5 
 for example). 

Such a mechanism will be necessary for trusted freesites in general - the 
reason we don't have an official freesite is what happens when the private 
key is compromised? The most basic scheme is to have a single revocation key, 
which if found indicates the key has been compromised, which can be inserted 
by trusted people. But it would be much better if each trusted person could 
have his own revocation key, and they could vote on adding new trusted 
people / kicking them out, and on recovery from a compromise of the main key.
 
 It would be possible to implement this check decentrally: Each head 
 must be signed by a majority of the keys which are saved in freenet 
 to be accepted locally, else the foreign repository will be marked as 
 compromised. 
 
 If the list of trusted keys is part of the repository, it will be possible 
to 
 update them. 
 
 Ideally there should also be a mechanism for backup locations and 
 changing them. For example this could be done by having a list of 
 them in the repository. When the main repository gets 
 compromised, freenet should check the backups for updates. 
 
 Adding in a few safety checks (always need backup locations and a 
 minimum number of maintainers), this looks to me like it should 
 work. 
 
 Are there any weeknesses in this scheme (except the possibility that 
 the majority of maintainers overlooks some bad code)? 

Dunno...
 
 Best wishes, 
 Arne


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

[freenet-dev] git/hg hosting

[David ‘Bombe’ Roden]

On Wednesday 08 April 2009 16:22:03 guido wrote:

> > Your pgp signature is charset corrupted.
> The pgp signature is pure ASCII, how can it possibly be charset corrupted?

Because there are encodings out there that don?t care about the lowest 7 bit 
being ASCII. Admittedly, they are far and in-between.


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: 

Re: [freenet-dev] git/hg hosting

[David ‘Bombe’ Roden]

On Wednesday 08 April 2009 16:22:03 guido wrote:

  Your pgp signature is charset corrupted.
 The pgp signature is pure ASCII, how can it possibly be charset corrupted?

Because there are encodings out there that don’t care about the lowest 7 bit 
being ASCII. Admittedly, they are far and in-between.


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

[freenet-dev] git/hg hosting

[guido]

Am Freitag, 3. April 2009 02:30:09 schrieb Daniel Cheng:
> > NextGen$
> >
> > -BEGIN PGP SIGNATURE-
>
> [..]
>
> > G3IAoIo?
>
> Your pgp signature is charset corrupted.

The pgp signature is pure ASCII, how can it possibly be charset corrupted?

Looks fine to me, btw.

-- 
|  _  | ASCII Ribbon Campaign Against HTML Emails.
| ( ) |
|  X  |
| / \ |

Re: [freenet-dev] git/hg hosting

[guido]

Am Freitag, 3. April 2009 02:30:09 schrieb Daniel Cheng:
  NextGen$
 
  -BEGIN PGP SIGNATURE-

 [..]

  G3IAoIo⎿伜堏鍙䶞㢈榷㑴

 Your pgp signature is charset corrupted.

The pgp signature is pure ASCII, how can it possibly be charset corrupted?

Looks fine to me, btw.

-- 
|  _  | ASCII Ribbon Campaign Against HTML Emails.
| ( ) |
|  X  |
| / \ |
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] git/hg hosting

[Daniel Cheng]

On Tue, Apr 7, 2009 at 4:11 PM, Arne Babenhauserheide  
wrote:
> Am Samstag 04 April 2009 03:29:57 schrieb David ?Bombe? Roden:
>> On Friday 03 April 2009 18:29:04 Arne Babenhauserheide wrote:
>> > > > $ hg sign [REVISION]
>> > >
>> > > git tag -s   -m 
>> >
>> > Is that a GnuPG signed tag?
>>
>> Yes. Check [1] for an example.
>
> Thanks!
>
> (also to Daniel Cheng who answered first :) )
>
> Can you also sign a revision without tagging it?

No.
In DVCS model, signing single revision does not make sense
 -- since you will merge / rebase that revision as soon as it is merged.

When you rebase a revision, the signature is voided.

>
> Best wishes,
> Arne

[freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Samstag 04 April 2009 22:50:11 schrieb Matthew Toseland:
> Agreed, however we need to be careful as we can be sued for any 
code which is copyrighted by somebody else; if we can provide the 
would-be litigant with the identity of the committer, we don't have 
this problem.

Sure. 

That's why someone needs to maintain a frenet-only pseudonymous 
version of the repository where all pseudonymous contributions can 
be gathered. :) 

That pseudonymous version can then contain additional features, so 
users have a rason for switching to it. 

We just need to find a way to make sure that this pseudonymous 
repository doesn't get compromised. 


I think it would be nice to do this as repository which can be updated 
only if at least 60% of a specific group of people agree. 

Ideally with also the option of adding new people to the group if 
enough people agree? 

Example: Assume that we have 5 trusted maintainers. If one of them 
now wants to push some changes to the reference repository, at 
least two others have to agree to get the new revision into freenet. 

If another maintainer joins the group, they need 4 people for pushing 
code online, and if two leave the group, two people suffice. (joining 
and leaving would need to be done as greoup decision - needs 3 of 5 
for example). 

It would be possible to implement this check decentrally: Each head 
must be signed by a majority of the keys which are saved in freenet 
to be accepted locally, else the foreign repository will be marked as 
compromised. 

If the list of trusted keys is part of the repository, it will be possible to 
update them. 

Ideally there should also be a mechanism for backup locations and 
changing them. For example this could be done by having a list of 
them in the repository. When the main repository gets 
compromised, freenet should check the backups for updates. 

Adding in a few safety checks (always need backup locations and a 
minimum number of maintainers), this looks to me like it should 
work. 

Are there any weeknesses in this scheme (except the possibility that 
the majority of maintainers overlooks some bad code)? 

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

Re: [freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Samstag 04 April 2009 03:29:57 schrieb 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.

Thanks! 

(also to Daniel Cheng who answered first :) )

Can you also sign a revision without tagging it? 

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
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Arne Babenhauserheide]

Am Samstag 04 April 2009 22:50:11 schrieb Matthew Toseland:
 Agreed, however we need to be careful as we can be sued for any 
code which is copyrighted by somebody else; if we can provide the 
would-be litigant with the identity of the committer, we don't have 
this problem.

Sure. 

That's why someone needs to maintain a frenet-only pseudonymous 
version of the repository where all pseudonymous contributions can 
be gathered. :) 

That pseudonymous version can then contain additional features, so 
users have a rason for switching to it. 

We just need to find a way to make sure that this pseudonymous 
repository doesn't get compromised. 


I think it would be nice to do this as repository which can be updated 
only if at least 60% of a specific group of people agree. 

Ideally with also the option of adding new people to the group if 
enough people agree? 

Example: Assume that we have 5 trusted maintainers. If one of them 
now wants to push some changes to the reference repository, at 
least two others have to agree to get the new revision into freenet. 

If another maintainer joins the group, they need 4 people for pushing 
code online, and if two leave the group, two people suffice. (joining 
and leaving would need to be done as greoup decision - needs 3 of 5 
for example). 

It would be possible to implement this check decentrally: Each head 
must be signed by a majority of the keys which are saved in freenet 
to be accepted locally, else the foreign repository will be marked as 
compromised. 

If the list of trusted keys is part of the repository, it will be possible to 
update them. 

Ideally there should also be a mechanism for backup locations and 
changing them. For example this could be done by having a list of 
them in the repository. When the main repository gets 
compromised, freenet should check the backups for updates. 

Adding in a few safety checks (always need backup locations and a 
minimum number of maintainers), this looks to me like it should 
work. 

Are there any weeknesses in this scheme (except the possibility that 
the majority of maintainers overlooks some bad code)? 

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
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] git/hg hosting

[Daniel Cheng]

On Tue, Apr 7, 2009 at 4:11 PM, Arne Babenhauserheide arne_...@web.de wrote:
 Am Samstag 04 April 2009 03:29:57 schrieb 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.

 Thanks!

 (also to Daniel Cheng who answered first :) )

 Can you also sign a revision without tagging it?

No.
In DVCS model, signing single revision does not make sense
 -- since you will merge / rebase that revision as soon as it is merged.

When you rebase a revision, the signature is voided.


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

[freenet-dev] git/hg hosting

[Ian Clarke]

On Mon, Apr 6, 2009 at 10:02 AM, Matthew Toseland
 wrote:
> On Sunday 05 April 2009 15:55:38 Daniel Cheng wrote:
>> Building untrusted binaries is not really impossible --
>> I have known some people running public build service with sandbox
>> for long. But these kind of service have high maintenance cost ...
>
> Well, no sandbox is perfect, and right now unit test changes are not so
> common...

Steve Hazel, former freenetter (way back around 2000-2001), built
this: http://codepad.org/.  It lets you run code in a variety of
languages in a robust sandbox.

He doesn't support Java because the JVM insists on starting other
threads, but he may have some advice for us about how to reasonably
sandbox a javac process.

If anyone is interested, I'm sure he'd be responsive to an email - his
addr is sah at codepad.org

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

[freenet-dev] git/hg hosting

[Matthew Toseland]

On Sunday 05 April 2009 15:55:38 Daniel Cheng wrote:
> On Sun, Apr 5, 2009 at 5:03 AM, Matthew Toseland
>  wrote:
> > On Thursday 02 April 2009 19:09:14 Ian Clarke wrote:
> >> Whichever source control system we switch to, I propose that we outsource
> >> the repository hosting. ?For example, if its git, we should use github.
> >>
> >> Reasons:
> >>
> >> - At least in the case of github, it will be free
> >> - We don't have to worry about setting up and administering the 
repository
> >> - Services like github have a lot of other useful add-ons like a nice web
> >> interface to the repository
> >> - Because of how git works, we can trivially migrate the repository
> >> elsewhere if there is a problem
> >>
> >> Anyone disagree? ?If so, why?
> >
> > IMHO hosting git (or hg) externally makes sense, for the reasons given and 
for
> > other reasons. Caveats relate to binaries/workflow:
> >
> > Stable builds: A trusted developer should review changes (from the 
repository
> > and not from the cvs list), create a tag and sign it, and then, on his own
> > computer, build the binaries and source tarballs for that build, and 
upload
> > them to our web hosting and to Freenet.
> >
> > Testing builds: We may or may not continue to provide testing builds. If 
we do
> > they should be an unofficial service, auto-built but should automatically
> > shut down if critical files (e.g. build.xml) are modified.
> 
> What if the junit are modified? junit are run on the sever as well

Good point. :(
> 
> Building untrusted binaries is not really impossible --
> I have known some people running public build service with sandbox
> for long. But these kind of service have high maintenance cost ...

Well, no sandbox is perfect, and right now unit test changes are not so 
common...
> 
> > The above is close to what we do now, but Done Right. In the long term we 
may
> > end up with a more distributed workflow, but it depends on what people 
want,
> > how it works out in practice; if I get a pseudonymous user asking me to 
pull
> > his in-Freenet repo (branch), I would certainly have a look!
> >>
> >> Ian.
-- 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: 

Re: [freenet-dev] git/hg hosting

[Matthew Toseland]

On Sunday 05 April 2009 15:55:38 Daniel Cheng wrote:
 On Sun, Apr 5, 2009 at 5:03 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  On Thursday 02 April 2009 19:09:14 Ian Clarke wrote:
  Whichever source control system we switch to, I propose that we outsource
  the repository hosting.  For example, if its git, we should use github.
 
  Reasons:
 
  - At least in the case of github, it will be free
  - We don't have to worry about setting up and administering the 
repository
  - Services like github have a lot of other useful add-ons like a nice web
  interface to the repository
  - Because of how git works, we can trivially migrate the repository
  elsewhere if there is a problem
 
  Anyone disagree?  If so, why?
 
  IMHO hosting git (or hg) externally makes sense, for the reasons given and 
for
  other reasons. Caveats relate to binaries/workflow:
 
  Stable builds: A trusted developer should review changes (from the 
repository
  and not from the cvs list), create a tag and sign it, and then, on his own
  computer, build the binaries and source tarballs for that build, and 
upload
  them to our web hosting and to Freenet.
 
  Testing builds: We may or may not continue to provide testing builds. If 
we do
  they should be an unofficial service, auto-built but should automatically
  shut down if critical files (e.g. build.xml) are modified.
 
 What if the junit are modified? junit are run on the sever as well

Good point. :(
 
 Building untrusted binaries is not really impossible --
 I have known some people running public build service with sandbox
 for long. But these kind of service have high maintenance cost ...

Well, no sandbox is perfect, and right now unit test changes are not so 
common...
 
  The above is close to what we do now, but Done Right. In the long term we 
may
  end up with a more distributed workflow, but it depends on what people 
want,
  how it works out in practice; if I get a pseudonymous user asking me to 
pull
  his in-Freenet repo (branch), I would certainly have a look!
 
  Ian.


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 Mon, Apr 6, 2009 at 10:02 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Sunday 05 April 2009 15:55:38 Daniel Cheng wrote:
 Building untrusted binaries is not really impossible --
 I have known some people running public build service with sandbox
 for long. But these kind of service have high maintenance cost ...

 Well, no sandbox is perfect, and right now unit test changes are not so
 common...

Steve Hazel, former freenetter (way back around 2000-2001), built
this: http://codepad.org/.  It lets you run code in a variety of
languages in a robust sandbox.

He doesn't support Java because the JVM insists on starting other
threads, but he may have some advice for us about how to reasonably
sandbox a javac process.

If anyone is interested, I'm sure he'd be responsive to an email - his
addr is s...@codepad.org

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

[freenet-dev] git/hg hosting

[Daniel Cheng]

On Sun, Apr 5, 2009 at 5:03 AM, Matthew Toseland
 wrote:
> On Thursday 02 April 2009 19:09:14 Ian Clarke wrote:
>> Whichever source control system we switch to, I propose that we outsource
>> the repository hosting. ?For example, if its git, we should use github.
>>
>> Reasons:
>>
>> - At least in the case of github, it will be free
>> - We don't have to worry about setting up and administering the repository
>> - Services like github have a lot of other useful add-ons like a nice web
>> interface to the repository
>> - Because of how git works, we can trivially migrate the repository
>> elsewhere if there is a problem
>>
>> Anyone disagree? ?If so, why?
>
> IMHO hosting git (or hg) externally makes sense, for the reasons given and for
> other reasons. Caveats relate to binaries/workflow:
>
> Stable builds: A trusted developer should review changes (from the repository
> and not from the cvs list), create a tag and sign it, and then, on his own
> computer, build the binaries and source tarballs for that build, and upload
> them to our web hosting and to Freenet.
>
> Testing builds: We may or may not continue to provide testing builds. If we do
> they should be an unofficial service, auto-built but should automatically
> shut down if critical files (e.g. build.xml) are modified.

What if the junit are modified? junit are run on the sever as well

Building untrusted binaries is not really impossible --
I have known some people running public build service with sandbox
for long. But these kind of service have high maintenance cost ...

> The above is close to what we do now, but Done Right. In the long term we may
> end up with a more distributed workflow, but it depends on what people want,
> how it works out in practice; if I get a pseudonymous user asking me to pull
> his in-Freenet repo (branch), I would certainly have a look!
>>
>> Ian.
>

Re: [freenet-dev] git/hg hosting

[Daniel Cheng]

On Sun, Apr 5, 2009 at 5:03 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 On Thursday 02 April 2009 19:09:14 Ian Clarke wrote:
 Whichever source control system we switch to, I propose that we outsource
 the repository hosting.  For example, if its git, we should use github.

 Reasons:

 - At least in the case of github, it will be free
 - We don't have to worry about setting up and administering the repository
 - Services like github have a lot of other useful add-ons like a nice web
 interface to the repository
 - Because of how git works, we can trivially migrate the repository
 elsewhere if there is a problem

 Anyone disagree?  If so, why?

 IMHO hosting git (or hg) externally makes sense, for the reasons given and for
 other reasons. Caveats relate to binaries/workflow:

 Stable builds: A trusted developer should review changes (from the repository
 and not from the cvs list), create a tag and sign it, and then, on his own
 computer, build the binaries and source tarballs for that build, and upload
 them to our web hosting and to Freenet.

 Testing builds: We may or may not continue to provide testing builds. If we do
 they should be an unofficial service, auto-built but should automatically
 shut down if critical files (e.g. build.xml) are modified.

What if the junit are modified? junit are run on the sever as well

Building untrusted binaries is not really impossible --
I have known some people running public build service with sandbox
for long. But these kind of service have high maintenance cost ...

 The above is close to what we do now, but Done Right. In the long term we may
 end up with a more distributed workflow, but it depends on what people want,
 how it works out in practice; if I get a pseudonymous user asking me to pull
 his in-Freenet repo (branch), I would certainly have a look!

 Ian.

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

[freenet-dev] git/hg hosting

[Matthew Toseland]

On Thursday 02 April 2009 19:09:14 Ian Clarke wrote:
> Whichever source control system we switch to, I propose that we outsource
> the repository hosting.  For example, if its git, we should use github.
> 
> Reasons:
> 
> - At least in the case of github, it will be free
> - We don't have to worry about setting up and administering the repository
> - Services like github have a lot of other useful add-ons like a nice web
> interface to the repository
> - Because of how git works, we can trivially migrate the repository
> elsewhere if there is a problem
> 
> Anyone disagree?  If so, why?

IMHO hosting git (or hg) externally makes sense, for the reasons given and for 
other reasons. Caveats relate to binaries/workflow:

Stable builds: A trusted developer should review changes (from the repository 
and not from the cvs list), create a tag and sign it, and then, on his own 
computer, build the binaries and source tarballs for that build, and upload 
them to our web hosting and to Freenet.

Testing builds: We may or may not continue to provide testing builds. If we do 
they should be an unofficial service, auto-built but should automatically 
shut down if critical files (e.g. build.xml) are modified.

The above is close to what we do now, but Done Right. In the long term we may 
end up with a more distributed workflow, but it depends on what people want, 
how it works out in practice; if I get a pseudonymous user asking me to pull 
his in-Freenet repo (branch), I would certainly have a look!
> 
> Ian.
-- 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: 

[freenet-dev] git/hg hosting

[Matthew Toseland]

On Friday 03 April 2009 15:50:28 Ian Clarke wrote:
> 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.  

You miss the point. The auto-build runs on emu, so having compromised emu you 
can  compromise emu! No net gain for any attacker.

> 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.

It is a legitimate concern, if it is misconfigured by either us or them. The 
right solution is for a trusted dev to code review, create a tag and sign it, 
and then release binaries from that tag. They can be built on his local 
machine, eliminating another reason for a central server hosted by us.
> 
> Ian.
-- 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: 

[freenet-dev] git/hg hosting

[Matthew Toseland]

On Friday 03 April 2009 09:31:06 Arne Babenhauserheide wrote:
> 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. 

Agreed, however we need to be careful as we can be sued for any code which is 
copyrighted by somebody else; if we can provide the would-be litigant with 
the identity of the committer, we don't have this problem.
-- 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: 

[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   -m 
> 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
-- 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: 

[freenet-dev] git/hg hosting

[Daniel Cheng]

2009/4/4 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?

"-s" is "sign"
>
> Best wishes,
> Arne

[freenet-dev] git/hg hosting

[Daniel Cheng]

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. 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?

Re: [freenet-dev] git/hg hosting

[Matthew Toseland]

On Friday 03 April 2009 09:31:06 Arne Babenhauserheide wrote:
 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. 

Agreed, however we need to be careful as we can be sued for any code which is 
copyrighted by somebody else; if we can provide the would-be litigant with 
the identity of the committer, we don't have this problem.


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

[Matthew Toseland]

On Friday 03 April 2009 15:50:28 Ian Clarke wrote:
 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.  

You miss the point. The auto-build runs on emu, so having compromised emu you 
can  compromise emu! No net gain for any attacker.

 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.

It is a legitimate concern, if it is misconfigured by either us or them. The 
right solution is for a trusted dev to code review, create a tag and sign it, 
and then release binaries from that tag. They can be built on his local 
machine, eliminating another reason for a central server hosted by us.
 
 Ian.


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

[Matthew Toseland]

On Thursday 02 April 2009 19:09:14 Ian Clarke wrote:
 Whichever source control system we switch to, I propose that we outsource
 the repository hosting.  For example, if its git, we should use github.
 
 Reasons:
 
 - At least in the case of github, it will be free
 - We don't have to worry about setting up and administering the repository
 - Services like github have a lot of other useful add-ons like a nice web
 interface to the repository
 - Because of how git works, we can trivially migrate the repository
 elsewhere if there is a problem
 
 Anyone disagree?  If so, why?

IMHO hosting git (or hg) externally makes sense, for the reasons given and for 
other reasons. Caveats relate to binaries/workflow:

Stable builds: A trusted developer should review changes (from the repository 
and not from the cvs list), create a tag and sign it, and then, on his own 
computer, build the binaries and source tarballs for that build, and upload 
them to our web hosting and to Freenet.

Testing builds: We may or may not continue to provide testing builds. If we do 
they should be an unofficial service, auto-built but should automatically 
shut down if critical files (e.g. build.xml) are modified.

The above is close to what we do now, but Done Right. In the long term we may 
end up with a more distributed workflow, but it depends on what people want, 
how it works out in practice; if I get a pseudonymous user asking me to pull 
his in-Freenet repo (branch), I would certainly have a look!
 
 Ian.


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

[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: 

[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: 

[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: 

[freenet-dev] git/hg hosting

[Florent Daignière]

* 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.

> 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: 

[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: 

[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: 

[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] 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: 

[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] 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

[freenet-dev] git/hg hosting

[NextGen$]

* Ian Clarke  [2009-04-02 13:09:14]:

> Whichever source control system we switch to, I propose that we outsource
> the repository hosting.  For example, if its git, we should use github.
> 
> Reasons:
> 
> - At least in the case of github, it will be free
> - We don't have to worry about setting up and administering the repository
> - Services like github have a lot of other useful add-ons like a nice web
> interface to the repository
> - Because of how git works, we can trivially migrate the repository
> elsewhere if there is a problem
> 
> Anyone disagree?  If so, why?
> 

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?

NextGen$

[freenet-dev] git/hg hosting

[Ian Clarke]

On Thu, Apr 2, 2009 at 1:55 PM, NextGen$ 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.

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: 

[freenet-dev] git/hg hosting

[Ian Clarke]

Whichever source control system we switch to, I propose that we outsource
the repository hosting.  For example, if its git, we should use github.

Reasons:

- At least in the case of github, it will be free
- We don't have to worry about setting up and administering the repository
- Services like github have a lot of other useful add-ons like a nice web
interface to the repository
- Because of how git works, we can trivially migrate the repository
elsewhere if there is a problem

Anyone disagree?  If so, why?

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: 

[freenet-dev] git/hg hosting

[Ian Clarke]

Whichever source control system we switch to, I propose that we outsource
the repository hosting.  For example, if its git, we should use github.

Reasons:

- At least in the case of github, it will be free
- We don't have to worry about setting up and administering the repository
- Services like github have a lot of other useful add-ons like a nice web
interface to the repository
- Because of how git works, we can trivially migrate the repository
elsewhere if there is a problem

Anyone disagree?  If so, why?

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

[NextGen$]

* Ian Clarke ian.cla...@gmail.com [2009-04-02 13:09:14]:

 Whichever source control system we switch to, I propose that we outsource
 the repository hosting.  For example, if its git, we should use github.
 
 Reasons:
 
 - At least in the case of github, it will be free
 - We don't have to worry about setting up and administering the repository
 - Services like github have a lot of other useful add-ons like a nice web
 interface to the repository
 - Because of how git works, we can trivially migrate the repository
 elsewhere if there is a problem
 
 Anyone disagree?  If so, why?
 

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?

NextGen$
___
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 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.

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

[Florent Daignière]

* 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.

NextGen$


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 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


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/3 Arne Babenhauserheide arne_...@web.de:
 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.
[...]
___
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/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.

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

 NextGen$

 -BEGIN PGP SIGNATURE-
[..]
 G3IAoIo⎿伜堏鍙䶞㢈榷㑴

Your pgp signature is charset corrupted.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl