Re: [Sks-devel] hg workflow pointers

2017-08-11 Thread Phil Pennock
On 2017-08-11 at 00:50 -0400, Daniel Kahn Gillmor wrote:
> One thing that might really sway me here would be if we could support a
> distributed view of the bug-tracker as well, but i don't know of any
> service that does that effectively right now.

Some candidates for consideration are listed in:
  https://dist-bugs.branchable.com/software/

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-11 Thread Kristian Fiskerstrand
On 08/10/2017 03:24 PM, Daniel Kahn Gillmor wrote:
> I'm
> not asking this question to push you or other hg-preferring developers
> out of sks, Jason, and would welcome suggestions for how to have a
> bigger tent.  sks suffers from a lack of active development, and we need
> more eyes on it if the OpenPGP community is going to continue to rely on
> keyservers.

Well, the level of activity reflects to some extent the stability of the
affected standards.. new features such as elliptic curves of various
kinds have been in released stable versions of SKS before other
implementations (naturally, since the complexity of searching and
storing is lower than using it).

The issues lately causing need for fixes is silly breakages in minor
version bumps in ocaml (I don't care that the developers say 4.04 to
4.05 is a major bump, its not, they need to get their versioning right
and stop doing silly API breaking stuff)

As for attracting new people; Its a specialized interest, very few have
a handle on OpenPGP overall, and uses vary greatly, e.g some focus more
on privacy than security, at which point keyserver might not be the
right thing for them to begin with due to social graph leak.

... noting of which is a result of the choie of VCS impacting this to a
great extent. If anything we'd need to rewrite the full codebase in C
for such an argument to be made.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"The power of accurate observation is commonly called cynicism by those
who have not got it."
George Bernard Shaw



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-11 Thread Kristian Fiskerstrand
On 08/11/2017 06:50 AM, Daniel Kahn Gillmor wrote:
> But anyway, this question is also orthogonal to whether we want to use
> hg or git, no?

Yes and no, it simplifies workflow reducing the importance of (i) and
(ii) for external contributors, and the patches aren't living in
long-term mercurial queues etc.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"The power of accurate observation is commonly called cynicism by those
who have not got it."
George Bernard Shaw



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-11 Thread Daniel Kahn Gillmor
On Tue 2017-08-08 15:27:46 +0200, Kristian Fiskerstrand wrote:
>  (i) Should we use git for revision control instead of mercurial?

this was the question i wanted to trigger -- i'm happy we're having the
discussion.

>  (ii)(A) Should we continue to use bitbucket (it also supports git so
> not dependent on (i)) or use another provider (if some of the questions
> are regarding the UI of bitbucket / its use) (B) if not bitbucket, what
> other alternative and why?

I don't really care about how the thing is hosted publicly as long as
it's a DVCS.  I have no strong objection to bitbucket, but i'd also have
no strong objection to gitlab or github or any other hosted service.

One thing that might really sway me here would be if we could support a
distributed view of the bug-tracker as well, but i don't know of any
service that does that effectively right now.

I'd also like it if such a decision doesn't derail the git/hg
decision-making.

>  (iii) Should we submit patches to the mailing list for review instead
> of using any platform's specific functionality?

If people are up for review on the mailing list, i think yes we should
do this.  Having an archive of patches in my mailbox is super useful
when i'm working offline, and i'd be happy to see some more active
discussion in the one place where we all are subscribed, for the health
of sks.

I regret that my ocaml skills are too weak to offer much in the way of
meaningful review, though :/

But anyway, this question is also orthogonal to whether we want to use
hg or git, no?

All the best,

   --dkg
   

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-10 Thread Daniel Kahn Gillmor
On Thu 2017-08-10 00:49:31 -0400, Jason Harris wrote:
> I prefer Mercurial - much lighter

I'm not sure what "lighter" means, but it's surely not about speed -- i
can clone a git repo the size of sks in a fraction of the time it takes
me to hg clone the sks repo.

> and much less risk of ruining your repo.

less risk of ruining *your* repo perhaps -- I've managed to ruin plenty
of hg repos myself, whereas my git repos are almost always in a useful
state, and when they're not i can recover them :)  Clearly i'm better at
ruining repos than you are :)

My point, of course, is: you probably have a better understanding of
what's going on in the hg internals and how to use its interface than i
do.  I feel more comfortable with git.  If the larger community prefers
hg, i'll continue being the person on the outside, but if most other
people are having the same frustrations i've had, and would feel more
comfortable with git, i'd be interested in considering a switch.  (i
recognize that would leave you "on the outside", which is no fun.)  I'm
not asking this question to push you or other hg-preferring developers
out of sks, Jason, and would welcome suggestions for how to have a
bigger tent.  sks suffers from a lack of active development, and we need
more eyes on it if the OpenPGP community is going to continue to rely on
keyservers.

--dkg

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-10 Thread Jason Harris

I prefer Mercurial - much lighter and much less risk of ruining your repo.

But, M$ has been hacking git: 
https://www.theregister.co.uk/2017/02/03/microsoft_foists_fake_file_system_for_fat_git_repos/

so maybe Windows 11 will be a total rewrite with zero reused code!  :)

Sent from my iPad

> On Aug 8, 2017, at 9:34 AM, Kristian Fiskerstrand 
>  wrote:
> 
>> On 08/08/2017 03:27 PM, Kristian Fiskerstrand wrote:
>> There are likely a few different questions resulting from this (my own
>> opinions in separate email).
> 
> And here they come
> 
>> (i) Should we use git for revision control instead of mercurial?
> 
> I'm personally more involved in projects using git these days, I am
> however not sure if this constitute grounds for shifting up platform of
> its own, but I'm curious what other's think. Mercurial has some great
> features (a reason e.g facebook:
> https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
> uses it, although we don't exactly have a scaling issue)
> 
>> (ii)(A) Should we continue to use bitbucket (it also supports git so
>> not dependent on (i)) or use another provider (if some of the questions
>> are regarding the UI of bitbucket / its use) (B) if not bitbucket, what
>> other alternative and why?
> 
> Open question, I don't see an immediate reason to move except for group
> effects of most others using github so no need to have a new account. I
> don't necessarily see centralization as a good thing overall, nor do I
> like the github ToS
> 
>> (iii) Should we submit patches to the mailing list for review instead
>> of using any platform's specific functionality?
> 
> I do think we should use the mailing list more actively to get more
> involvement in the development; in particular with the low level of
> commits proper review can only be a good thing. This can likely also
> result in more complete commit message etc for individual commits with
> the discussion in email archives as reference.
> 
> -- 
> 
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> 
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> "In politics stupidity is not a handicap."
> (Napoleon Bonaparte)
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-08 Thread Kristian Fiskerstrand
On 08/08/2017 03:27 PM, Kristian Fiskerstrand wrote:
> that is added
> as a single commit upon qmerge

To avoid any ambiguity, this should be qfinish... qmerge is similar step
in the Gentoo Portage process...

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Prævenire melius est quam præveniri
It is better to precede than to be preceded



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-08 Thread Kristian Fiskerstrand
On 08/08/2017 03:27 PM, Kristian Fiskerstrand wrote:
> There are likely a few different questions resulting from this (my own
> opinions in separate email).

And here they come

>  (i) Should we use git for revision control instead of mercurial?

I'm personally more involved in projects using git these days, I am
however not sure if this constitute grounds for shifting up platform of
its own, but I'm curious what other's think. Mercurial has some great
features (a reason e.g facebook:
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
uses it, although we don't exactly have a scaling issue)

>  (ii)(A) Should we continue to use bitbucket (it also supports git so
> not dependent on (i)) or use another provider (if some of the questions
> are regarding the UI of bitbucket / its use) (B) if not bitbucket, what
> other alternative and why?

Open question, I don't see an immediate reason to move except for group
effects of most others using github so no need to have a new account. I
don't necessarily see centralization as a good thing overall, nor do I
like the github ToS

>  (iii) Should we submit patches to the mailing list for review instead
> of using any platform's specific functionality?

I do think we should use the mailing list more actively to get more
involvement in the development; in particular with the low level of
commits proper review can only be a good thing. This can likely also
result in more complete commit message etc for individual commits with
the discussion in email archives as reference.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"In politics stupidity is not a handicap."
(Napoleon Bonaparte)



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-08 Thread Kristian Fiskerstrand
On 08/01/2017 11:30 PM, Daniel Kahn Gillmor wrote:
> Is there a comparably simple tutorial someone can point me to for
> contributing to sks?
> 

What I'm using myself, and is supported by bitbucket is mercurial patch
queues (MQ extension)

https://www.mercurial-scm.org/wiki/MqExtension /
https://www.mercurial-scm.org/wiki/MqTutorial , which allows to push and
pop from patch queue / qseries, allowing for separate commits within the
patch series that isn't part of the regular master branch, that is added
as a single commit upon qmerge

... That said...

> or, would sks folks be interested in moving to git for revision control?

There are likely a few different questions resulting from this (my own
opinions in separate email).
 (i) Should we use git for revision control instead of mercurial?
 (ii)(A) Should we continue to use bitbucket (it also supports git so
not dependent on (i)) or use another provider (if some of the questions
are regarding the UI of bitbucket / its use) (B) if not bitbucket, what
other alternative and why?
 (iii) Should we submit patches to the mailing list for review instead
of using any platform's specific functionality?

Now, (iii) possibly invalidates (i) and (ii) as the workflow is
simplified (hg export), so in terms of the processes of commits and we'd
avoid any move (wiki and issue tracker stays the same).

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Aquila non capit muscas
The eagle does not hunt flies



signature.asc
Description: OpenPGP digital signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] hg workflow pointers

2017-08-07 Thread Yaron Minsky
Without saying anything about how to use hg (though this is a nice
tutorial: http://hginit.com/), I have no objection to moving the whole
thing to git and/or github. I was the one who chose hg long ago, and I no
longer work on SKS enough for my opinion on such things to matter.

y

On Tue, Aug 1, 2017 at 5:30 PM, Daniel Kahn Gillmor 
wrote:

> hey folks--
>
> i'm comfortable with git.  i'm even comfortable on github, gitlab, and
> other similar platforms.
>
> I'm not as comfortable with mercurial (hg), or with bitbucket's hg
> interface, but i think i'm educable.  This is a request for pointers for
> simple workflow help.
>
> i find that every time i want to propose a simple change to the sks
> project in a convenient way for upstream (e.g. as a pull request), i
> spend hours beating my head against the wall.
>
> with git, i would do something like:
>
> git clone $UPSTREAM_REPO
> cd $REPO_NAME
> git checkout -b $FEATURE_BRANCH_NAME
> $EDITOR example.source
> git add example.source
> git commit -m 'explanation of change'
> git push origin $FEATURE_BRANCH_NAME
>
> Then i would go to whatever goofy webui the project uses and
> clicky-clicky through to make a "merge request" or a "pull request".
>
> In situations where i don't have push access to the $UPSTREAM_REPO
> (which is fine) i make a "fork" (i.e. my own copy) of the repo on the
> upstream hosting platform, and i pull from there and push to there
> instead.  (the clicky-clicky bit of making a "merge request" or "pull
> request" is then slightly more complicated)
>
> I've even tried to do this on bitbucket for sks, with:
>
> https://bitbucket.org/dkgdkg/sks-keyserver.old
>
> But it's possible that i've screwed that repo up badly enough that i
> can't get it to do what i'd want to do.  and i can't convince bitbucket
> to let me make a new "fork" of the upstream sks-keyserver either :/
>
> Is there a comparably simple tutorial someone can point me to for
> contributing to sks?
>
> or, would sks folks be interested in moving to git for revision control?
>
> --dkg, frustrated at having spent too much of the day on
>   administrivia instead of actual contributions
>
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel