Re: Is it okay to clone OpenBSD from GitHub from India?

[Dinesh Thirumurthy]

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?

[Stuart Henderson]

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?

[Dinesh Thirumurthy]

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?

[Stefan Sperling]

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?

[Dinesh Thirumurthy]

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

[Otto Moerbeek]

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?

[Dinesh Thirumurthy]

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

[Dinesh Thirumurthy]

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: OpenBSD on GitHub

[Reyk Floeter]

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

[zz]

 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

[K . André Braselmann]

git sucks. mercurial ruleZ, i want a mercurial mirror.
And python in base... and some icecream.

André

2012/8/6 Franco Fichtner slash...@gmail.com:
 On Aug 6, 2012, at 12:02 PM, Marc Espie es...@nerim.net 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

[Marc Espie]

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

[Franco Fichtner]

On Aug 6, 2012, at 12:02 PM, Marc Espie es...@nerim.net 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

[Stuart Henderson]

On 2012-08-04, Tony ableton...@gmail.com 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

[Darrin Chandler]

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

[Ted Unangst]

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

[Darrin Chandler]

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

[Theo de Raadt]

 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

[Kenneth R Westerback]

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

[Darrin Chandler]

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

I think Git can support the workflow you want, but that doesn't matter.
I do not expect or want to change your mind, and do not expect to see an
official OpenBSD git repo soon, if ever. It should only ever happen if
it makes sense to you and the other OpenBSD devs, to further the
underlying goals of the project. Until then, it would be stupid to
switch. So at this point I don't even *want* you to switch. Not yet,
anyway.

OpenBSD on GitHub

[Tony]

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

[Peter Hessler]

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

Re: OpenBSD on GitHub

[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 ableton...@gmail.com 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

[Janne Johansson]

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 use...@gmail.com:
 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 ableton...@gmail.com 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

[Marc Espie]

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

[Matthew Dempsky]

On Sat, Aug 4, 2012 at 6:43 AM, Tony ableton...@gmail.com 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.