Re: OT: Github requiring 2FA auth, meaning
NB: forjo -> forgejo Anyone has experienced Gitee? Any feedback? -- Daniele Bonini
Re: OT: Github requiring 2FA auth, meaning
I have been an expat in China for five long years, I know perfectly what does it mean software serving "power and big financial interests" and this should remain in the meaning of this thread when it about 2FA auth serving Github. -- Daniele Bonini Aug 31, 2023 04:32:36 lain. : > > Microsoft outright owns Github itself, it acquired Github back in 2018, > yet go many "I HATE EVERYTHING MICROSOFT" people choose to ignore that > fact.
Re: OT: Github requiring 2FA auth, meaning
Aug 31, 2023 04:02:56 Kastus Shchuka : > > You may make as many jokes about Microsoft as you want, but please > remember that Microsoft Corporation has been gold or silver donor > of the OpenBSD Foundation for the past 7 years [1] > > 1. http://www.openbsdfoundation.org/contributors.html Now don't joke about AI against OpenBSD code, lol
Re: OT: Github requiring 2FA auth, meaning
On 2023年08月30日 17:59, the silly Kastus Shchuka claimed to have said: > You may make as many jokes about Microsoft as you want, but please > remember that Microsoft Corporation has been gold or silver donor > of the OpenBSD Foundation for the past 7 years [1] > > 1. http://www.openbsdfoundation.org/contributors.html > I don't consider that to be the same thing. If you donate, you don't pull any strings, and you're not part of the decission making process, you are if you sponsor or god forbid, invest though. Microsoft outright owns Github itself, it acquired Github back in 2018, yet go many "I HATE EVERYTHING MICROSOFT" people choose to ignore that fact. -- lain.
Re: OT: Github requiring 2FA auth, meaning
On Thu, Aug 31, 2023 at 08:59:46AM +0900, lain. wrote: > On 2023年08月30日 19:35, the silly Daniele B. claimed to have said: > > Finally I activated a couple of 2FA options on my Github account > > Imagine entrusting Microsoft with your source code lol. You may make as many jokes about Microsoft as you want, but please remember that Microsoft Corporation has been gold or silver donor of the OpenBSD Foundation for the past 7 years [1] 1. http://www.openbsdfoundation.org/contributors.html
Re: OT: Github requiring 2FA auth, meaning
On 2023年08月30日 19:35, the silly Daniele B. claimed to have said: > Finally I activated a couple of 2FA options on my Github account Imagine entrusting Microsoft with your source code lol. -- lain.
Re: OT: Github requiring 2FA auth, meaning
Finally I activated a couple of 2FA options on my Github account including the app authentication, for helping I include also the link of the app link I'm just checking out (2FAS app https://play.google.com/store/apps/details?id=com.twofasapp) Thinking this one as the least losing solution. Keep mainly the "meaning" of thread and thanks everyone for the replies. -- Daniele Bonini Aug 29, 2023 23:08:41 Stuart Henderson : > On 2023-08-29, Daniele B. wrote: >> Today I received comunication that my Github account "needs" 2FA >> authentication before 12th October 2023. > > you can use a fido key, or you can use totp (which doesn't need any > hardware if you don't care about storing the key in an enclave, you > can just use oathtool or similar)
Re: OT: Github requiring 2FA auth, meaning
On 2023-08-29, Daniele B. wrote: > Today I received comunication that my Github account "needs" 2FA > authentication before 12th October 2023. you can use a fido key, or you can use totp (which doesn't need any hardware if you don't care about storing the key in an enclave, you can just use oathtool or similar)
Re: OT: Github requiring 2FA auth, meaning
On Tue, Aug 29, 2023 at 08:40:38PM +0200, Daniele B. wrote: > Since today powers and financial interests will be able to block me > access to the Github platform by their discrection. All ready for > that? Yes, Firefox from ports seems to handle Yubikey 2FA just fine. Best regards, Chris Narkiewicz
OT: Github requiring 2FA auth, meaning
Hello everyone, Today I received comunication that my Github account "needs" 2FA authentication before 12th October 2023. Since today powers and financial interests will be able to block me access to the Github platform by their discrection. All ready for that? My reccomandation: let's start to think to Github alternatives, most probably distributed. http://5md.io/l/2862274 -- Daniele Bonini
Re: Github has openbsd_hammer2fs
On 2023-08-22, dues_openbsd wrote: > hi, dears. > recently, I get the email by friends > it says Github has openbsd_hammer2fs and makefs. yes, seen that in january. kusumi (who is working on hammer2 in dragonfly and has accounts there+netbsd) has diffs for *read-only* hammer2 on freebsd/netbsd/openbsd, i'm not aware of it being done with reference to openbsd devs however. > Is that means. It will be "The OpenBSD can use The Modern journaling file > system". > > The OpenBSD could be include "openbsd_hammer2fs" in default system? all it means at the moment is "there's some code on github". > (I know "google summer code 2011" says "hammer2fs will be in OpenBSD ". but, > rejected, is that correct?) i don't recall the details though looking at the proposal now, i think the suggest timescale is rather optimistic. > > https://github.com/kusumi/openbsd_hammer2 > > https://github.com/kusumi/makefs -- Please keep replies on the mailing list.
Re: Github has openbsd_hammer2fs
There are lots of projects on Github. Sometimes, they have the word "openbsd" in the title or README. Those are added by the author. Any discussion about inclusion in OpenBSD will happen on the OpenBSD mailing lists, and most certainly not in any github project, pr, issue, or whatever else they have. Until it has been committed to the OpenBSD src tree, it won't be included in the default system. On 2023 Aug 22 (Tue) at 16:28:08 + (+), dues_openbsd wrote: :hi, dears. :recently, I get the email by friends :it says Github has openbsd_hammer2fs and makefs. : :Is that means. It will be "The OpenBSD can use The Modern journaling file system". : :The OpenBSD could be include "openbsd_hammer2fs" in default system? : :(I know "google summer code 2011" says "hammer2fs will be in OpenBSD ". but, rejected, is that correct?) : :https://github.com/kusumi/openbsd_hammer2 : :https://github.com/kusumi/makefs
Github has openbsd_hammer2fs
hi, dears. recently, I get the email by friends it says Github has openbsd_hammer2fs and makefs. Is that means. It will be "The OpenBSD can use The Modern journaling file system". The OpenBSD could be include "openbsd_hammer2fs" in default system? (I know "google summer code 2011" says "hammer2fs will be in OpenBSD ". but, rejected, is that correct?) https://github.com/kusumi/openbsd_hammer2 https://github.com/kusumi/makefs Sent with [Proton Mail](https://proton.me/) secure email.
Re: Github/Bitbucket free alternative
On Mon, Apr 04, 2022 at 01:07:49PM +0800, Tito Mari Francis Escaño said: > I'm trying to develop web apps on OpenBSD but Github and even Bitbucket > seems to think that only Windows and/or Linux are the platforms so I feel > forced to use VS Code that runs only on those systems. git(1) works just fine on OpenBSD. --Matt
Re: Github/Bitbucket free alternative
On Mon, Apr 04, 2022 at 01:07:49PM +0800, Tito Mari Francis Escaño wrote: > Hi everyone, > I'm trying to develop web apps on OpenBSD but Github and even Bitbucket > seems to think that only Windows and/or Linux are the platforms so I feel > forced to use VS Code that runs only on those systems. > Can somebody please point me to alternative free online code repository > services that I can use with OpenBSD? > Thanks and stay safe everyone :) I use git and the gh cli with github on OpenBSD without issues. As you do not tell use what your actual issues are it's hard to help you. -Otto
Re: Github/Bitbucket free alternative
Tito Mari Francis Escaño wrote: > Hi everyone, > I'm trying to develop web apps on OpenBSD but Github and even Bitbucket > seems to think that only Windows and/or Linux are the platforms so I feel > forced to use VS Code that runs only on those systems. > Can somebody please point me to alternative free online code repository > services that I can use with OpenBSD? > Thanks and stay safe everyone :) It's almost like some a software ecosystem pandemic is happening. Stay safe.
Github/Bitbucket free alternative
Hi everyone, I'm trying to develop web apps on OpenBSD but Github and even Bitbucket seems to think that only Windows and/or Linux are the platforms so I feel forced to use VS Code that runs only on those systems. Can somebody please point me to alternative free online code repository services that I can use with OpenBSD? Thanks and stay safe everyone :)
Re: Is it okay to clone OpenBSD from GitHub from India?
Stuart, > The conversion on github is done with cvs2gitdump. Thanks very much. I will try this. > For git-cvs here's a snip from the mail I wrote Uwe back in 2015: > > << When an update is committed to a file that was previously imported, > the import is shown again in "git log". It looks like it happens for the > first commit after import. >> Okay. Thanks. I hope to understand it better when I do it myself. I am looking to create a git repo outside USA/Canada for to serve a whole bunch of people downstream. I do not expect users/students/teachers to have great connectivity, Disconnected operation is important for me/my users. I believe if students start tracking OpenBSD current and keep recompiling OpenBSD nightly, they will feel pumped and probably do more coding, look around the various parts of it, and then I will be able to reach out to a whole set of graduates who will become proficient C programmers, using 1 UNIX-like OS (OpenBSD here). Better still, they are programming on a solid production grade OS. I am seeing that effect on myself and my intern. :-) You always end up liking something if you have built/assembled it or have been a part of building it. I recently came to know that is called the IKEA Effect [https://en.wikipedia.org/wiki/IKEA_effect]. I think OpenBSD, git, a git hosting server(TBD) and VirtualBox will be good combination. Thanks again for your help. Regards, Dinesh
Re: Is it okay to clone OpenBSD from GitHub from India?
On 2017-12-23, Dinesh Thirumurthy wrote:
> Stephan,
>
> Thank you.
>
>> Note that openbsd's github conversion is not considered stable yet.
>
> I was using github.com because it is (ahem) more palatable. :-)
> So, it should be a hit with students.
>
>> Which means all commit hashes could change at any time. Regardless
>> of the crypto export issue, I would not rely on it for very important
>> tasks until it is declared stable.
>
> Okay. I fine with that.
>
>> If you really want it in git format without legal trouble, you could
>> create your own git conversion with e.g. git-cvs ('pkg_add git-cvs').
>
> Thanks very much. I was trying to get in touch with Bob Beck to figure
> this out.
>
> Regards,
> Dinsh
>
>
>
The conversion on github is done with cvs2gitdump. After testing all of
the conversion tools I could find, this was the one which had the fewest
problems with OpenBSD's slightly broken rcs files. (In particular,
anything which tries to convert branches is very likely to break).
For git-cvs here's a snip from the mail I wrote Uwe back in 2015:
<< When an update is committed to a file that was previously imported,
the import is shown again in "git log". It looks like it happens for the
first commit after import. >>
Re: Is it okay to clone OpenBSD from GitHub from India?
Stephan,
Thank you.
> Note that openbsd's github conversion is not considered stable yet.
I was using github.com because it is (ahem) more palatable. :-)
So, it should be a hit with students.
> Which means all commit hashes could change at any time. Regardless
> of the crypto export issue, I would not rely on it for very important
> tasks until it is declared stable.
Okay. I fine with that.
> If you really want it in git format without legal trouble, you could
> create your own git conversion with e.g. git-cvs ('pkg_add git-cvs').
Thanks very much. I was trying to get in touch with Bob Beck to figure
this out.
Regards,
Dinsh
Re: Is it okay to clone OpenBSD from GitHub from India?
On Sat, Dec 23, 2017 at 05:19:54PM +0530, Dinesh Thirumurthy wrote:
>
> > Just use cvs from a mirror outisde the US? You don't *need* to use
> > github, github is a copy anyway and only cvs is authorative.
> >
> > -Otto
>
> Otto,
>
> Thanks.
>
> I was trying to distribute a tweaked OpenBSD to teachers and students in
> India, so they could compile kernel, base, and xenocara very easily.
> Not that it is difficult now. But just made it easier. I was using
> github.com as my distribution platform from a forked OpenBSD. Now I need
> to find another way to distribute it.
>
> Regards,
> Dinesh
>
>
Note that openbsd's github conversion is not considered stable yet.
Which means all commit hashes could change at any time. Regardless
of the crypto export issue, I would not rely on it for very important
tasks until it is declared stable.
If you really want it in git format without legal trouble, you could
create your own git conversion with e.g. git-cvs ('pkg_add git-cvs').
Re: Is it okay to clone OpenBSD from GitHub from India?
> Just use cvs from a mirror outisde the US? You don't *need* to use > github, github is a copy anyway and only cvs is authorative. > > -Otto Otto, Thanks. I was trying to distribute a tweaked OpenBSD to teachers and students in India, so they could compile kernel, base, and xenocara very easily. Not that it is difficult now. But just made it easier. I was using github.com as my distribution platform from a forked OpenBSD. Now I need to find another way to distribute it. Regards, Dinesh
Re: Is it okay to clone OpenBSD from GitHub from India?
On Sat, Dec 23, 2017 at 04:24:22PM +0530, Dinesh Thirumurthy wrote: > >From https://www.openbsd.org/cvsync.html > > " IMPORTANT NOTE: There are a few issues relating to cryptographic > software that everyone should be aware of: > ... > However, if you are outside the USA or Canada, you should not fetch > the cryptographic sections of the OpenBSD sources from a CVSync server > located in the USA. The files in question are... > src/kerberosIV/* > src/kerberosV/* > src/lib/libdes/* > src/lib/libc/crypt/crypt.c > src/lib/libc/crypt/morecrypt.c > src/sys/crypto > src/sys/netinet > src/usr.sbin/afs/src/rxkad/* > > Because of the USA ITAR munitions list, crypto software may only be > exported to Canada from the USA." > > generalising cvsync server to any version control software server, we > get: > > "if you are outside the USA or Canada, you should not fetch the > cryptographic sections of the OpenBSD sources from **any > version control software** server located in the USA" > > That would include github.com > > so is using the combination (OpenBSD, GitHub, India) uncool (gulp > illegal)? > > If illegal, this kind of sucks for me and my intern. > > May be someone experienced in these matters could confirm/deny? > > Thanks, > Dinesh Just use cvs from a mirror outisde the US? You don't *need* to use github, github is a copy anyway and only cvs is authorative. -Otto
Re: Is it okay to clone OpenBSD from GitHub from India?
>From https://www.openbsd.org/cvsync.html " IMPORTANT NOTE: There are a few issues relating to cryptographic software that everyone should be aware of: ... However, if you are outside the USA or Canada, you should not fetch the cryptographic sections of the OpenBSD sources from a CVSync server located in the USA. The files in question are... src/kerberosIV/* src/kerberosV/* src/lib/libdes/* src/lib/libc/crypt/crypt.c src/lib/libc/crypt/morecrypt.c src/sys/crypto src/sys/netinet src/usr.sbin/afs/src/rxkad/* Because of the USA ITAR munitions list, crypto software may only be exported to Canada from the USA." generalising cvsync server to any version control software server, we get: "if you are outside the USA or Canada, you should not fetch the cryptographic sections of the OpenBSD sources from **any version control software** server located in the USA" That would include github.com so is using the combination (OpenBSD, GitHub, India) uncool (gulp illegal)? If illegal, this kind of sucks for me and my intern. May be someone experienced in these matters could confirm/deny? Thanks, Dinesh
Is it okay to clone OpenBSD from GitHub from India?
Hi, "(NOTE: OpenBSD can not be re-exported from the US once it has entered the US. Because of this, take care NOT to get the distribution from a mirror server in the US if you are outside of Canada and the US.)" I am not in US/Canada. So is it okay to get OpenBSD source from GitHub? git clone https://github.com/openbsd/src.git github.com servers are in USA. Thanks. Dinesh
Re: github
On Mon, Aug 8, 2016 at 7:56 PM, David Schmidt wrote: > Nick Holland wrote: > >Nowhere on the OpenBSD website mentions github as anything official. > > It does on this page: https://www.openbsd.org/libressl/. Its even > above the cvs link. Of course this is just for libressl not for the > rest of openbsd. > > We use github as a mirrorâ for LibreSSL-portable and OpenNTPD-portable too. It's not unlike the official python github mirror, which is synced from that project's Mercurial repo: https://github.com/python/cpython If you have patches for the openbsd@ side of these projects, it is best to just email them to tech@, since the OpenBSD devs only have so many places they will look for patches on a regular basis. Using git format-patch, send-email or similar work well in my experience. On the 'portable' side, github PRs are fine, since I'm using git natively and can fetch from the github mirror directly.
Re: github
On Mon, 8 Aug 2016 17:56:30 -0700 David Schmidt wrote: > Nick Holland wrote: > >Nowhere on the OpenBSD website mentions github as anything > >official. > > It does on this page: https://www.openbsd.org/libressl/. Its even > above the cvs link. Of course this is just for libressl not for the > rest of openbsd. > Nice observation David :) Now regarding those libressl n00bz... I mean github... really? REALLY? *disclaimer* This is sarcasm, I'm just trolling. Personally I don't like github in the same way I don't like any other 'cloud' service, but that's just me. -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: github
Nick Holland wrote: >Nowhere on the OpenBSD website mentions github as anything official. It does on this page: https://www.openbsd.org/libressl/. Its even above the cvs link. Of course this is just for libressl not for the rest of openbsd.
Re: github
Karel Gardas [gard...@gmail.com] wrote: > OpenBSD is using CVS solely, but for my own purposes I started to > mirror src to github recently using cvs2gitdump tool. I do this since > I find git log/git show more friendly than CVS provided tools... If > you are interested see https://github.com/kgardas/openbsd-src -- Thank you. I personally find these git browsers to be convenient, mostly because I can look at one entire commit in a click. So, this depends on cvs2gitdump being accurately able to identify commits that are part of the same action. For my regular diff browsing, it's probably fine :)
Re: github
On Mon, 08 Aug 2016 11:42 +0200, frantisek holop wrote:
> [...] another low friction and low time investment approach could
> have been to proactively take these usernames/urls and put
> placeholders or links to the official project site.
Why should the project do put up links on its site for any rando
dood{,ette}'s repo/site? It doesn't make any sense.
Re: github
Nick Holland, 07 Aug 2016 23:36: > > Is this http://[bullshit deleted]/openbsd the official OpenBSD github site? > > I find this part terrifying. > > Nowhere on the OpenBSD website mentions github as anything official. So > you just assumed that the seven letters, "openbsd", in that order, makes > it officially part of the project? No. Examples of this will be found > all over the Internet. i am confused about the shock and terror. i don't have code on github, but through ports we are all github users in one way or another. github is popular and everyone and his dog has either their official repo or a mirror on there. so while taking github links at face value is not correct, it happens all the time and until something else replaces it, it will get only worse. and that brings me to my second point. impersonating projects/persons on popular services (twitter, etc) is as old as domain squating and while it's ok for the openbsd project to totally ignore these filthy nasty new age services, another low friction and low time investment approach could have been to proactively take these usernames/urls and put placeholders or links to the official project site. -f -- the greatest hate springs from the greatest love.
Re: github
On 08/07/16 08:44, Dariusz Sendkowski wrote: > Is this http://[bullshit deleted]/openbsd the official OpenBSD github site? I find this part terrifying. Nowhere on the OpenBSD website mentions github as anything official. So you just assumed that the seven letters, "openbsd", in that order, makes it officially part of the project? No. Examples of this will be found all over the Internet. How about lock graphics on websites and the word "secure"? Internet 101: anyone can put anything in any URL. Or twisting Duke Ellington, "It don't mean a thing, just 'cause it has a string" Nick.
Re: github
OpenBSD is using CVS solely, but for my own purposes I started to mirror src to github recently using cvs2gitdump tool. I do this since I find git log/git show more friendly than CVS provided tools... If you are interested see https://github.com/kgardas/openbsd-src -- CAVEAT! Do not trust the source code there and especially do not use it for your own OpenBSD build. In case of any doubts please use OpenBSD CVS's src as a reference. BTW I've tried to search among src's mirror on github.com but all were out-dated and needed to have src in git after spacehopper.org's git stopped working... On Sun, Aug 7, 2016 at 6:57 PM, Dariusz Sendkowski wrote: > 2016-08-07 18:42 GMT+02:00 Chris Bennett < > chrisbenn...@bennettconstruction.us>: > >> On Sun, Aug 07, 2016 at 10:06:56AM -0600, Jack J. Woehr wrote: >> > whereas on GitHub it would belong to a corporation. >> > >> > Doesn't that simply end the discussion right there? >> >> Yes. >> This thread has been informative to me. >> Forget the silly move from CVS part, never was an issue. >> >> I did NOT know that GitHub was a corporation. I find that very >> disturbing. Extremely disturbing. >> >> May all your pkg_* include: >> pkg_delete git >> > > > I'm afraid you're confusing git with github. > > > >> >> So there was a jewel to be found in this thread. >> Thank you all for this. >> >> Sorry if I was a bit noisy, I'm just so tired of seeing so many projects >> hooked on git. It's like a fad. What's next? Turdd. Shitt. Crapplee.
Re: github
2016-08-07 18:42 GMT+02:00 Chris Bennett < chrisbenn...@bennettconstruction.us>: > On Sun, Aug 07, 2016 at 10:06:56AM -0600, Jack J. Woehr wrote: > > whereas on GitHub it would belong to a corporation. > > > > Doesn't that simply end the discussion right there? > > Yes. > This thread has been informative to me. > Forget the silly move from CVS part, never was an issue. > > I did NOT know that GitHub was a corporation. I find that very > disturbing. Extremely disturbing. > > May all your pkg_* include: > pkg_delete git > I'm afraid you're confusing git with github. > > So there was a jewel to be found in this thread. > Thank you all for this. > > Sorry if I was a bit noisy, I'm just so tired of seeing so many projects > hooked on git. It's like a fad. What's next? Turdd. Shitt. Crapplee.
Re: github
On Sun, Aug 07, 2016 at 10:06:56AM -0600, Jack J. Woehr wrote: > whereas on GitHub it would belong to a corporation. > > Doesn't that simply end the discussion right there? Yes. This thread has been informative to me. Forget the silly move from CVS part, never was an issue. I did NOT know that GitHub was a corporation. I find that very disturbing. Extremely disturbing. May all your pkg_* include: pkg_delete git So there was a jewel to be found in this thread. Thank you all for this. Sorry if I was a bit noisy, I'm just so tired of seeing so many projects hooked on git. It's like a fad. What's next? Turdd. Shitt. Crapplee.
Re: github
> On 18:12 Sun 07 Aug, ludovic coues wrote: > > 2016-08-07 18:00 GMT+02:00 Consus : > > > On 10:56 Sun 07 Aug, Chris Bennett wrote: > > >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > > >> > Sign your commits with GPG. Looky, a link: > > >> > > > >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > > >> > > > >> > Not that hard, is it? > > >> > > > >> > > >> OK, you win. > > >> > > >> Would you do me a favor first. > > >> Before this big move, could you make a commit to the OpenBSD CVS tree? > > >> Anything would do. Just find a file that has spaces where it should have > > >> tabs. Commit your diff. Once you do that, I think all of the developers > > >> will be easily convinced to move to Github. > > > > > > Err... What? > > > > > > > You are talking big while not contributing to the project. > > So? I'm not stating YOU GUYS SHOULD MOVE TO GITHUB RIGHT NOW. I'm > stating that "github is not secure" is bullshit. > Just stop it. We are not going to listen to you.
Re: github
>From all discussions: 1) a solution looking for a problem 2) the problems github tries to address are not considered urgent nor important problems by OpenBSD developers 3) migration cost/benefit is not worth it - and using 2 different methods of VC take away focus from the team". On Sunday, 7 August 2016, Jack J. Woehr wrote: > Ingo Schwarze wrote: > >> Hi, >> >> Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 02:44:58PM +0200: >> >> Is this https://github.com/openbsd the official OpenBSD github site? >>> >> As one of the OpenBSD developers, i don't know and frankly i don't >> care. You certainly shouldn't trust it in any way. >> > > It seems this discussion has gone on quite a while without stating the > obvious: > > 1. The developers are happy with CVS. > 2. As is, OpenBSD has full goddawmitey control of their source repository > whereas on GitHub it would belong to a corporation. > > Doesn't that simply end the discussion right there? > > -- > Jack J. Woehr # Science is more than a body of knowledge. It's a way of > www.well.com/~jax # thinking, a way of skeptically interrogating the > universe > www.softwoehr.com # with a fine understanding of human fallibility. - > Carl Sagan
Re: github
On 18:12 Sun 07 Aug, ludovic coues wrote: > 2016-08-07 18:00 GMT+02:00 Consus : > > On 10:56 Sun 07 Aug, Chris Bennett wrote: > >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > >> > Sign your commits with GPG. Looky, a link: > >> > > >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > >> > > >> > Not that hard, is it? > >> > > >> > >> OK, you win. > >> > >> Would you do me a favor first. > >> Before this big move, could you make a commit to the OpenBSD CVS tree? > >> Anything would do. Just find a file that has spaces where it should have > >> tabs. Commit your diff. Once you do that, I think all of the developers > >> will be easily convinced to move to Github. > > > > Err... What? > > > > You are talking big while not contributing to the project. So? I'm not stating YOU GUYS SHOULD MOVE TO GITHUB RIGHT NOW. I'm stating that "github is not secure" is bullshit.
Re: github
2016-08-07 18:00 GMT+02:00 Consus : > On 10:56 Sun 07 Aug, Chris Bennett wrote: >> On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: >> > Sign your commits with GPG. Looky, a link: >> > >> > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work >> > >> > Not that hard, is it? >> > >> >> OK, you win. >> >> Would you do me a favor first. >> Before this big move, could you make a commit to the OpenBSD CVS tree? >> Anything would do. Just find a file that has spaces where it should have >> tabs. Commit your diff. Once you do that, I think all of the developers >> will be easily convinced to move to Github. > > Err... What? > You are talking big while not contributing to the project. -- Cordialement, Coues Ludovic +336 148 743 42
Re: github
Ingo Schwarze wrote: Hi, Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 02:44:58PM +0200: Is this https://github.com/openbsd the official OpenBSD github site? As one of the OpenBSD developers, i don't know and frankly i don't care. You certainly shouldn't trust it in any way. It seems this discussion has gone on quite a while without stating the obvious: 1. The developers are happy with CVS. 2. As is, OpenBSD has full goddawmitey control of their source repository whereas on GitHub it would belong to a corporation. Doesn't that simply end the discussion right there? -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan
Re: github
On 10:56 Sun 07 Aug, Chris Bennett wrote: > On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > > Sign your commits with GPG. Looky, a link: > > > > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > > > > Not that hard, is it? > > > > OK, you win. > > Would you do me a favor first. > Before this big move, could you make a commit to the OpenBSD CVS tree? > Anything would do. Just find a file that has spaces where it should have > tabs. Commit your diff. Once you do that, I think all of the developers > will be easily convinced to move to Github. Err... What?
Re: github
On Sun, Aug 07, 2016 at 06:43:02PM +0300, Consus wrote: > Sign your commits with GPG. Looky, a link: > > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work > > Not that hard, is it? > OK, you win. Would you do me a favor first. Before this big move, could you make a commit to the OpenBSD CVS tree? Anything would do. Just find a file that has spaces where it should have tabs. Commit your diff. Once you do that, I think all of the developers will be easily convinced to move to Github.
Re: github
On 10:35 Sun 07 Aug, Chris Bennett wrote: > On Sun, Aug 07, 2016 at 11:17:21AM -0400, Donald Allen wrote: > > > Date: Sun, 7 Aug 2016 17:59:07 +0300 > > > From: con...@gmx.com > > > To: > > misc@openbsd.org > > > Subject: Re: github > > > > > > > And github offers two-factor authentication, so if enabled, not simple > > to hack the account. > > > > Github is running OpenBSD? I didn't know that. > That's a relief. I wouldn't trust any of my critical data with any less > secure Operating Ayatem. Sign your commits with GPG. Looky, a link: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work Not that hard, is it?
Re: github
On Sun, Aug 7, 2016 at 11:17 AM, Donald Allen wrote: >> Date: Sun, 7 Aug 2016 17:59:07 +0300 >> From: con...@gmx.com >> To: > misc@openbsd.org >> Subject: Re: github >> >> On 16:43 Sun 07 Aug, Ingo Schwarze > wrote: >>>> Do you have any plans to move the OpenBSD source code repository >>>> to github? >>> >>> Absolutely not. The OpenBSD repository will remain > secure and >>> will not be outsourced to a random third party. >> >> I'm sorry, > are we talking about the same OpenBSD CVS tree that does not >> offer any kind > of encryption and transfers all your data in plain over >> the network (except > for developers who use SSH of course)? How's that >> secure? >> >> Moreover, Git > itself allows you to check what the hell is going on using >> your local > history (e.g. git pull will not work without some love if >> somebody changes > your repo on the GitHub side without your awareness). >> Also signed commits > FWIW. > > And github offers two-factor authentication, so if enabled, not simple > to hack the account. > The openBSD tree is duplicated over the SSH protocol, not HTTPS; You are spreading miss information. -- - () ascii ribbon campaign - against html e-mail /\
Re: github
On Sun, Aug 07, 2016 at 11:17:21AM -0400, Donald Allen wrote: > > Date: Sun, 7 Aug 2016 17:59:07 +0300 > > From: con...@gmx.com > > To: > misc@openbsd.org > > Subject: Re: github > > > > And github offers two-factor authentication, so if enabled, not simple > to hack the account. > Github is running OpenBSD? I didn't know that. That's a relief. I wouldn't trust any of my critical data with any less secure Operating Ayatem.
Re: github
> Date: Sun, 7 Aug 2016 17:59:07 +0300 > From: con...@gmx.com > To: misc@openbsd.org > Subject: Re: github > > On 16:43 Sun 07 Aug, Ingo Schwarze wrote: >>> Do you have any plans to move the OpenBSD source code repository >>> to github? >> >> Absolutely not. The OpenBSD repository will remain secure and >> will not be outsourced to a random third party. > > I'm sorry, are we talking about the same OpenBSD CVS tree that does not > offer any kind of encryption and transfers all your data in plain over > the network (except for developers who use SSH of course)? How's that > secure? > > Moreover, Git itself allows you to check what the hell is going on using > your local history (e.g. git pull will not work without some love if > somebody changes your repo on the GitHub side without your awareness). > Also signed commits FWIW. And github offers two-factor authentication, so if enabled, not simple to hack the account.
Re: github
On 16:43 Sun 07 Aug, Ingo Schwarze wrote: > > Do you have any plans to move the OpenBSD source code repository > > to github? > > Absolutely not. The OpenBSD repository will remain secure and > will not be outsourced to a random third party. I'm sorry, are we talking about the same OpenBSD CVS tree that does not offer any kind of encryption and transfers all your data in plain over the network (except for developers who use SSH of course)? How's that secure? Moreover, Git itself allows you to check what the hell is going on using your local history (e.g. git pull will not work without some love if somebody changes your repo on the GitHub side without your awareness). Also signed commits FWIW.
Re: github
Hi, Dariusz Sendkowski wrote on Sun, Aug 07, 2016 at 02:44:58PM +0200: > Is this https://github.com/openbsd the official OpenBSD github site? As one of the OpenBSD developers, i don't know and frankly i don't care. You certainly shouldn't trust it in any way. Personally, i consider github commercial crap that is utterly unusable for anything. If you send me a github link, i'm very likely to completely ignore it even if i would in principle be quite interested in the content, simply because i'm not willing to waste my time on the crappy user interface. > Do you have any plans to move the OpenBSD source code repository > to github? Absolutely not. The OpenBSD repository will remain secure and will not be outsourced to a random third party. Even if OpenBSD, at some point in the future, would decide to do anything with git, i would very strongly oppose doing anything official whatsoever with github. Yours, Ingo
Re: github
Thanks. Original message From: Mike Burns Date: 8/7/16 14:51 (GMT+01:00) To: Dariusz Sendkowski Cc: misc Subject: Re: github On 2016-08-07 14.44.58 +0200, Dariusz Sendkowski wrote: > Is this https://github.com/openbsd the official OpenBSD github site? > Do you have any plans to move the OpenBSD source code repository to github? http://marc.info/?l=openbsd-misc&m=134408828426309&w=2
Re: github
On 2016-08-07 14.44.58 +0200, Dariusz Sendkowski wrote: > Is this https://github.com/openbsd the official OpenBSD github site? > Do you have any plans to move the OpenBSD source code repository to github? http://marc.info/?l=openbsd-misc&m=134408828426309&w=2
github
Is this https://github.com/openbsd the official OpenBSD github site? Do you have any plans to move the OpenBSD source code repository to github?
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 05:35:47PM -0400, Kenneth R Westerback wrote: > On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: > > On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: > > > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: > > >> Well, git just has a different set of bugs than cvs. > > > ... > > >> I would deem cvs MORE painful than git on average, it's just that > > >> we're more accustomed to the pain... > > > > > > Yes, this is right. And also there would be a price to pay in lost > > > productivity in switching to a new system. To those very familiar with > > > CVS and not very familiar with Git (or hg, et al), the benefits of > > > switching are nebulous and uncertain, while the cost is very real. > > > > I will add a somewhat controversial viewpoint to the mix. Because cvs > > makes working with branches and large diffs so painful, it forces > > developers to split their work into smaller pieces. In OpenBSD, > > that's a good thing. Keeping your changes in a private fork is > > difficult, which is good. It means fewer private forks. If every > > developer could maintain a branch with some private tweaks, and not > > bother integrating their changes or fixing regressions, progress would > > grind to a halt. [I have mentioned this to people before and their > > eyes just about popped out of their head. I don't expect > > everyone to agree.] > > ++1 here. My only experience with a project that moved from cvs to > git was that a) the number of brances exploded and b) the number > of repositories containing branches exploded and were erratically > interconnected. > > This resulted in many rotting branches, many private playgrounds > and far less incentive to move forward together. I particularly > enjoyed messages containing lists of random hex numbers that one > should revert, merge with or sacrifice chickens over if one could > only find the appropriate repository. > I can share that we had the same experience when we started to use git at work: exploded and rotting branches, playgrounds, and all these troubles with git-isms and endless ways to do the same thing. But, quite frankly, it is a sign that a) the release maintenance sucks. b) the willingness and experience to master git is missing. After more than two years, we got used to git, established stricter rules, and I think we got rid of these problems plus having some of the benefits and reliefs over CVS (see espie's mail for a few examples). Most importantly, unused branches have to be deleted from the server, people have to work and develop in "master", and arbitrary experiments do not belong on the shared remote, unless they are important or intereting for others. If people do not test their changes in master, they will keep on breaking the tree and you'll have to deal with them personally (I think that is the "social" part of the model). After all, git is not github. The latter is the same old bazaar-like model where everyone does something somewhere and it eventually turns into releases, excluding quality. You do not have to use git like that, but it is a learning curve for people who only knew github. You can use git in a more traditional, centralized and self-hosted way. > OK, one experience but it left an indelible impression. :-) > > I think git gives you a lot of rope. It does. I'm fine with using CVS in OpenBSD. Reyk
Re: OpenBSD on GitHub
> git sucks. mercurial ruleZ, i want a mercurial mirror. > And python in base... and some icecream. > python and mercurial sucks both. Both have nothing to do with true UNIX heritage. Use Ubuntu
Re: OpenBSD on GitHub
git sucks. mercurial ruleZ, i want a mercurial mirror. And python in base... and some icecream. André 2012/8/6 Franco Fichtner : > On Aug 6, 2012, at 12:02 PM, Marc Espie wrote: > >> Well, I have an actual list of advantages that git may offer: > > Thanks, Marc. Good listing! I wonder what CVS brings to the table on the > bright side? > > I understand everything that's been said. I've even come to hate GPL'ed > software just because of using the license in the first place (didn't come up > yet, but I know this is an issue, too). But I don't think git would be the > downfall of OpenBSD. There's too much drive and too much brains at work to go > down the slippery slope. But don't let that get to your heads. :P > > Git doesn't force a workflow on you. Where I used to work, I'd rather have > everyone push their changes to the master (or trunk) commit by commit, telling > them to break down larger changes, keeping bug fixes and features separate, > wiping out stupid merges that did not even cause any conflicts, etc. Linux > Kernel maintainers have done this for years, even the manual apply of hundreds > of emailed patches. > > You can go the other way and maintain a -load of local patches, ponder on > dead-end feature branches, do trigger happy merges, but you don't have to at > all. Rebasing patches to avoid merges is the holy grail of git. Cherry-picking > the most interesting commits on top of this functionality is even more > awesome. Ok, back to the original question... > > Having an up-to-date git read-only mirror (on github, or where ever it's hip > to put it) would be nice. I really don't mind the hipster crowd to go and fork > the repository. I don't think those people would bother going through the > painful process of sending patches the OpenBSD way with all the hassles in > place. Maybe like this, it's going to be easier to grab stuff as a maintainer > and get more exposure on general. > > > Franco
Re: OpenBSD on GitHub
On Aug 6, 2012, at 12:02 PM, Marc Espie wrote: > Well, I have an actual list of advantages that git may offer: Thanks, Marc. Good listing! I wonder what CVS brings to the table on the bright side? I understand everything that's been said. I've even come to hate GPL'ed software just because of using the license in the first place (didn't come up yet, but I know this is an issue, too). But I don't think git would be the downfall of OpenBSD. There's too much drive and too much brains at work to go down the slippery slope. But don't let that get to your heads. :P Git doesn't force a workflow on you. Where I used to work, I'd rather have everyone push their changes to the master (or trunk) commit by commit, telling them to break down larger changes, keeping bug fixes and features separate, wiping out stupid merges that did not even cause any conflicts, etc. Linux Kernel maintainers have done this for years, even the manual apply of hundreds of emailed patches. You can go the other way and maintain a -load of local patches, ponder on dead-end feature branches, do trigger happy merges, but you don't have to at all. Rebasing patches to avoid merges is the holy grail of git. Cherry-picking the most interesting commits on top of this functionality is even more awesome. Ok, back to the original question... Having an up-to-date git read-only mirror (on github, or where ever it's hip to put it) would be nice. I really don't mind the hipster crowd to go and fork the repository. I don't think those people would bother going through the painful process of sending patches the OpenBSD way with all the hassles in place. Maybe like this, it's going to be easier to grab stuff as a maintainer and get more exposure on general. Franco
Re: OpenBSD on GitHub
Well, I have an actual list of advantages that git may offer: - better patch/diff handling capabilities. CVS is very crappy at that. As soon as you are testing stuff locally, every update request will produce conflicts. git has very good merging capabilities, comparatively. - possibility to have commits that make sense, and are not just one file at a time. - cheap tags. Makes it trivial to tag a release, or hey, even to tag the tree a release is made off. Sometimes, I would actually enjoy knowing what diffs a binary snapshot contains. - being able to prepare logical commits. git is much better than cvs at handling patch sets. - bisecting for bugs. - moving files sucks with cvs. - being able to prepare diffs with new directories. CVS currently really sucks at that. You more or less need to have a local repository copy (which is possible thru various tools), because otherwise, adding a directory will commit to the distant repository. As far as cvs is concerned, by far, the most annoying nit I have is with bad merges if I had a nickel for every hour I spent cleaning up merge disasters in a tree... I would be rich. I've looked at GNU cvs code and it's not pretty (it does very weird things on import branches). Pity OpenCVS is not really going anywhere (don't look at me to advance it, I have already too many projects going on, and I don't fancy writing diff/sdiff primitives in C).
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 02:14:56PM -0600, Theo de Raadt wrote: > > I don't find this controversial, except the notion that sticking with > > blunt tools to solve a human/procedural problem is a good idea. > > How else should I, as the maintainer of the trunk, contain the damage > from these human/procedural problems? Careful -- every suggestion you > want to suggest now makes the job of the trunk maintainer harder. > Every single one of them. > > If people don't depend on the trunk as their primary, the trunk rots. > If people have easy branch tools, they use the branches. > > > It also doesn't work, even if it appears to work: how many devs have > > I heard talk about a local tree they've maintained for a long time > > with changes that haven't yet gone in? Quite a few. > > Those are not public branches. They are used by one (maybe two) > developers to advance something big. I agree. If I implied that public branches were good then I should have been more clear. The "-current is (almost) always best" and "release like clockwork" attitudes have paid large dividends, and that goes hand in hand with trunk working as you say. The private branches (or whole separate trees!) seem like another matter to me. In git, working with branches and keeping them in sync is fairly easy, as is sharing directly (not through the central repo) with others. > But not everything is big. Lots of important things are very small, > and don't need a branch. Yet the answer heard over and over again is: > branches are good, they should be used for almost everything. Except > once again, that infects those people's trees, and they don't test the > trunk, and once instabilities are introduced by another developer they > abandon the head of the trunk and run something else and we don't get > those bugs fixed until the release process. I see other projects > falling into this problem all the time. It is awesome. Back when CVS was in widespread use, people still did stupid things. They do stupid things now with git. I'm one of those people who like to make branches for everything, but I still test against trunk. Of course I do. That's what will get committed to the central repo, so that's what matters. > > When the changes go in, they come in small chunks, but the > > long-lived forks exist. > > No, these long-lived forks are deleted when their changes go into the > trunk. They are just a local development process tool; some people > manage to do them without rcs type models, yet others like their own > rcs's. > > Here in OpenBSD, there are no such long lived forks. Maybe somewhere > else. But look at the list you are on... This time I was definitely unclear. Yes, delete after merging with trunk. > > Small commits are largely preferred by pretty much all of the > > sensible people I know, and OpenBSD culture clearly prefers/demands > > them. I'd be surprised if giving people sharper tools would do much > > harm. > > Ha ha. I watch other projects. You see what looks like "small > commits", except the care of moving things from their own branch to > the trunk is often highly sloppy -- by nature people are careless and > will not re-test their trunk commits independently. So they break the > head of the trunk. This pisses off developers who rely on the trunk. > Eventually they learn to rely on their own safer branches and only > update once in a while when the trunk is safe. Do you see where this > is going? Incredible division of labour when it comes to testing. > And who eventually gets burned the most by this? The release > engineer... if a release is ever done. I won't vouch for what unsensible people do. Of the various ways I've seen people do things, "trunk is reliable" works the best by a long shot in my experience. You can do the "trunk is gee whiz cutting edge" with CVS, too. We've both seen projects do that with CVS. It stinks. But that's not a CVS vs. Git thing. > > > github is all about social coding and they have a point. But many > > > of the things they enable are considered antisocial in the OpenBSD > > > development process. > > > > There can be public read-only git without github, and I'd think > > self-hosting would be a much better fit for OpenBSD. > > If people only used such trees for reading, fine. But they will run > them, and then not test the trunk. Every 6 months we ship the trunk. > How does it become solid if everyone runs something else? I'm not sure this would be the case to any larger degree than now, but I don't understand your reasoning there so it's likely I'm missin
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: > On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: > > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: > >> Well, git just has a different set of bugs than cvs. > > ... > >> I would deem cvs MORE painful than git on average, it's just that > >> we're more accustomed to the pain... > > > > Yes, this is right. And also there would be a price to pay in lost > > productivity in switching to a new system. To those very familiar with > > CVS and not very familiar with Git (or hg, et al), the benefits of > > switching are nebulous and uncertain, while the cost is very real. > > I will add a somewhat controversial viewpoint to the mix. Because cvs > makes working with branches and large diffs so painful, it forces > developers to split their work into smaller pieces. In OpenBSD, > that's a good thing. Keeping your changes in a private fork is > difficult, which is good. It means fewer private forks. If every > developer could maintain a branch with some private tweaks, and not > bother integrating their changes or fixing regressions, progress would > grind to a halt. [I have mentioned this to people before and their > eyes just about popped out of their head. I don't expect > everyone to agree.] ++1 here. My only experience with a project that moved from cvs to git was that a) the number of brances exploded and b) the number of repositories containing branches exploded and were erratically interconnected. This resulted in many rotting branches, many private playgrounds and far less incentive to move forward together. I particularly enjoyed messages containing lists of random hex numbers that one should revert, merge with or sacrifice chickens over if one could only find the appropriate repository. OK, one experience but it left an indelible impression. :-) I think git gives you a lot of rope. Which people use to hang themselves (and others!) as often as they use it to build a safety net. ... Ken > > github is all about social coding and they have a point. But many > of the things they enable are considered antisocial in the OpenBSD > development process.
Re: OpenBSD on GitHub
> I don't find this controversial, except the notion that sticking with > blunt tools to solve a human/procedural problem is a good idea. How else should I, as the maintainer of the trunk, contain the damage from these human/procedural problems? Careful -- every suggestion you want to suggest now makes the job of the trunk maintainer harder. Every single one of them. If people don't depend on the trunk as their primary, the trunk rots. If people have easy branch tools, they use the branches. > It also > doesn't work, even if it appears to work: how many devs have I heard > talk about a local tree they've maintained for a long time with changes > that haven't yet gone in? Quite a few. Those are not public branches. They are used by one (maybe two) developers to advance something big. But not everything is big. Lots of important things are very small, and don't need a branch. Yet the answer heard over and over again is: branches are good, they should be used for almost everything. Except once again, that infects those people's trees, and they don't test the trunk, and once instabilities are introduced by another developer they abandon the head of the trunk and run something else and we don't get those bugs fixed until the release process. I see other projects falling into this problem all the time. It is awesome. > When the changes go in, they come > in small chunks, but the long-lived forks exist. No, these long-lived forks are deleted when their changes go into the trunk. They are just a local development process tool; some people manage to do them without rcs type models, yet others like their own rcs's. Here in OpenBSD, there are no such long lived forks. Maybe somewhere else. But look at the list you are on... > Small commits are > largely preferred by pretty much all of the sensible people I know, and > OpenBSD culture clearly prefers/demands them. I'd be surprised if giving > people sharper tools would do much harm. Ha ha. I watch other projects. You see what looks like "small commits", except the care of moving things from their own branch to the trunk is often highly sloppy -- by nature people are careless and will not re-test their trunk commits independently. So they break the head of the trunk. This pisses off developers who rely on the trunk. Eventually they learn to rely on their own safer branches and only update once in a while when the trunk is safe. Do you see where this is going? Incredible division of labour when it comes to testing. And who eventually gets burned the most by this? The release engineer... if a release is ever done. > > github is all about social coding and they have a point. But many > > of the things they enable are considered antisocial in the OpenBSD > > development process. > > There can be public read-only git without github, and I'd think > self-hosting would be a much better fit for OpenBSD. If people only used such trees for reading, fine. But they will run them, and then not test the trunk. Every 6 months we ship the trunk. How does it become solid if everyone runs something else?
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: > I will add a somewhat controversial viewpoint to the mix. Because cvs > makes working with branches and large diffs so painful, it forces > developers to split their work into smaller pieces. In OpenBSD, > that's a good thing. Keeping your changes in a private fork is > difficult, which is good. It means fewer private forks. If every > developer could maintain a branch with some private tweaks, and not > bother integrating their changes or fixing regressions, progress would > grind to a halt. [I have mentioned this to people before and their > eyes just about popped out of their head. I don't expect > everyone to agree.] I don't find this controversial, except the notion that sticking with blunt tools to solve a human/procedural problem is a good idea. It also doesn't work, even if it appears to work: how many devs have I heard talk about a local tree they've maintained for a long time with changes that haven't yet gone in? Quite a few. When the changes go in, they come in small chunks, but the long-lived forks exist. Small commits are largely preferred by pretty much all of the sensible people I know, and OpenBSD culture clearly prefers/demands them. I'd be surprised if giving people sharper tools would do much harm. > github is all about social coding and they have a point. But many > of the things they enable are considered antisocial in the OpenBSD > development process. There can be public read-only git without github, and I'd think self-hosting would be a much better fit for OpenBSD.
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: > On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: >> Well, git just has a different set of bugs than cvs. > ... >> I would deem cvs MORE painful than git on average, it's just that >> we're more accustomed to the pain... > > Yes, this is right. And also there would be a price to pay in lost > productivity in switching to a new system. To those very familiar with > CVS and not very familiar with Git (or hg, et al), the benefits of > switching are nebulous and uncertain, while the cost is very real. I will add a somewhat controversial viewpoint to the mix. Because cvs makes working with branches and large diffs so painful, it forces developers to split their work into smaller pieces. In OpenBSD, that's a good thing. Keeping your changes in a private fork is difficult, which is good. It means fewer private forks. If every developer could maintain a branch with some private tweaks, and not bother integrating their changes or fixing regressions, progress would grind to a halt. [I have mentioned this to people before and their eyes just about popped out of their head. I don't expect everyone to agree.] github is all about social coding and they have a point. But many of the things they enable are considered antisocial in the OpenBSD development process.
Re: OpenBSD on GitHub
On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: > Well, git just has a different set of bugs than cvs. ... > I would deem cvs MORE painful than git on average, it's just that > we're more accustomed to the pain... Yes, this is right. And also there would be a price to pay in lost productivity in switching to a new system. To those very familiar with CVS and not very familiar with Git (or hg, et al), the benefits of switching are nebulous and uncertain, while the cost is very real. Over time, OpenBSD has done things that were in the "no, never, just go away" category just a few years before. I would not be too surprised if OpenBSD switched to a DVCS in the future, when it's a well considered switch and not a headlong rush into "the next new thing." To those of us who see the benefits of DVCS it's frsutrating to wait, but OpenBSD has avoided many pitfalls by being conservative. In the meantime, OpenBSD uses CVS, and it's workable.
Re: OpenBSD on GitHub
On 2012-08-04, Tony wrote: > Personally I'd love to make a fork and contribute back a ton of pull > requests, mostly on the documentation side though. No need for all this complication of exporting/syncing between the version control system used by OpenBSD and another one for work directories - just work on an anoncvs checkout directly. The only operation that you can't do easily against an anonymous CVS server is adding a new directory, and in the majority of cases this is only an issue for ports diffs. N.B. if sending diffs (inline not attached) you'll probably need to use something other than the gmail web interface to send diffs as it usually corrupts them so that they don't apply cleanly.
Re: OpenBSD on GitHub
On Sat, Aug 4, 2012 at 6:43 AM, Tony wrote: > Personally I'd love to make a fork and contribute back a ton of pull > requests, mostly on the documentation side though. What's easier/nicer about github's pull request than sending an email with an enclosed diff? I use git for a lot of my local development too, but CVS is going to remain OpenBSD's Single Source of Truth for the foreseeable future. Using github pull requests just means passing the buck in terms of who's responsible for actually getting the diff into CVS.
Re: OpenBSD on GitHub
On Sat, Aug 04, 2012 at 05:47:47PM +0200, Janne Johansson wrote: > Also, diffs from git has proven to not apply cleanly at times (for > reasons unknown to me), so whatever you hope the versioning tool will > let you do, don't forget to make sure any contributions do apply. Well, git just has a different set of bugs than cvs. Considering how many times "cvs import" has fucked up my tree and required hand-holding (gcc imports mostly), it's only a matter of "you know more about cvs than git"... I would deem cvs MORE painful than git on average, it's just that we're more accustomed to the pain...
Re: OpenBSD on GitHub
Also, diffs from git has proven to not apply cleanly at times (for reasons unknown to me), so whatever you hope the versioning tool will let you do, don't forget to make sure any contributions do apply. We will not do that for you, just to accommodate different VC systems that people fancy at the moment. 2012/8/4 Luis Useche : > You don't have to ask permission to anyone to do whatever you want > with the OpenBSD code. If you can create a github account that > reliably mirror OpenBSD's commits, I think some people would be > interested. > > For what is worth, there is already a git repository that follows > OpenBSD: http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/. However, > I have found it unreliable and that is why I don't use it. > > Luis. > > On Sat, Aug 4, 2012 at 9:43 AM, Tony wrote: >> Hey! >> >> Guys, what do you think about putting OpenBSD on GitHub? I see you guys >> already have an account there so I just thought I'd ask: >> https://github.com/openbsd >> >> Will it attract more followers? Will it make life easier for developers? >> >> Personally I'd love to make a fork and contribute back a ton of pull >> requests, mostly on the documentation side though. >> >> Tony > -- To our sweethearts and wives. May they never meet. -- 19th century toast
Re: OpenBSD on GitHub
You don't have to ask permission to anyone to do whatever you want with the OpenBSD code. If you can create a github account that reliably mirror OpenBSD's commits, I think some people would be interested. For what is worth, there is already a git repository that follows OpenBSD: http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/. However, I have found it unreliable and that is why I don't use it. Luis. On Sat, Aug 4, 2012 at 9:43 AM, Tony wrote: > Hey! > > Guys, what do you think about putting OpenBSD on GitHub? I see you guys > already have an account there so I just thought I'd ask: > https://github.com/openbsd > > Will it attract more followers? Will it make life easier for developers? > > Personally I'd love to make a fork and contribute back a ton of pull > requests, mostly on the documentation side though. > > Tony
Re: OpenBSD on GitHub
No. This has been discussed many times before, and we have no interest in this. On 2012 Aug 04 (Sat) at 15:43:37 +0200 (+0200), Tony wrote: :Hey! : :Guys, what do you think about putting OpenBSD on GitHub? I see you guys :already have an account there so I just thought I'd ask: :https://github.com/openbsd : :Will it attract more followers? Will it make life easier for developers? : :Personally I'd love to make a fork and contribute back a ton of pull :requests, mostly on the documentation side though. : :Tony : -- "... the Mayo Clinic, named after its founder, Dr. Ted Clinic ..." -- Dave Barry
OpenBSD on GitHub
Hey! Guys, what do you think about putting OpenBSD on GitHub? I see you guys already have an account there so I just thought I'd ask: https://github.com/openbsd Will it attract more followers? Will it make life easier for developers? Personally I'd love to make a fork and contribute back a ton of pull requests, mostly on the documentation side though. Tony
Re: The (unofficial) opebsd repo in github is outdated
On Sat, 14 Jan 2012 01:46:50 +0100, joshua stein wrote: The openbsd repo in github is outdated. Are the owners reading the list? Can someone update the repo?. Github doesn't show me a contact address for the "organization", so I thing this list is the best option for report the problem. the cvs-to-git conversion tool i was using was not producing 100% accurate trees, leaving some extra files in some of the release branches and causing some builds to break. the trees were not being updated while i was resuming work on my own conversion tool to fix these problems. since a few people have asked about them, i've just deleted the github repos to avoid confusion. the new trees will have different histories and git commit hashes so they will need to be re-downloaded/forked anyway. i will push the new trees back up to github when the tool is finished and i have verified that all of the branches are identical to the cvs versions. Thanks for your work. I noticed the problem in December but I preferred give some of time to the owners before of report the problem. I was reading yesterday about the available conversion tools cvs -> git. The conversion seems a very complex task. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: The (unofficial) opebsd repo in github is outdated
> The openbsd repo in github is outdated. Are the owners reading the > list? Can someone update the repo?. Github doesn't show me a contact > address for the "organization", so I thing this list is the best > option for report the problem. the cvs-to-git conversion tool i was using was not producing 100% accurate trees, leaving some extra files in some of the release branches and causing some builds to break. the trees were not being updated while i was resuming work on my own conversion tool to fix these problems. since a few people have asked about them, i've just deleted the github repos to avoid confusion. the new trees will have different histories and git commit hashes so they will need to be re-downloaded/forked anyway. i will push the new trees back up to github when the tool is finished and i have verified that all of the branches are identical to the cvs versions.
Re: The (unofficial) opebsd repo in github is outdated
On Sat, 14 Jan 2012 01:37:49 +0100, Stuart Henderson wrote: Do not use it, the import tool is broken. OK. Thanks. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: The (unofficial) opebsd repo in github is outdated
Do not use it, the import tool is broken. On 2012-01-13, Juan Francisco Cantero Hurtado wrote: > Firstly, sorry if this is a bit off-topic for the list. > > The openbsd repo in github is outdated. Are the owners reading the list? > Can someone update the repo?. Github doesn't show me a contact address for > the "organization", so I thing this list is the best option for report the > problem. > > Thanks.
The (unofficial) opebsd repo in github is outdated
Firstly, sorry if this is a bit off-topic for the list. The openbsd repo in github is outdated. Are the owners reading the list? Can someone update the repo?. Github doesn't show me a contact address for the "organization", so I thing this list is the best option for report the problem. Thanks. -- Juan Francisco Cantero Hurtado http://juanfra.info
