Re: [Sks-devel] hg workflow pointers
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
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
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
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
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
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
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
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
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
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 Gillmorwrote: > 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