Discussion:
Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model
(too old to reply)
John Luke Gibson
2017-05-31 13:19:54 UTC
Permalink
Raw Message
Neverminding the ridiculous length of that subject line..

I just thought an interesting thought.

First, a little context, (I know how rms feels about blockchains) I
was investigating slock.it and thinking to myself "why don't they just
make a hardware standard like eoma instead of closing their
development and calling it open?" (Like, Pi-Top is [n]ever gonna
release those stl files)
(I realize that's a loaded 'just' cause it sounds easy, but is one of
the most difficult possible)

Then, it dawned on me: Lulzbot doesn't do that.. Wait, Lulzbot
exclusively uses open software in their development.. Then *bam* like
a boulder (nothing to do with Lulzbot): GPL-violations, improper GUI
training, failing to extend using APIs/Addons, failing to
bugsmash/'track-issues', failing to participate in mailing-lists and
irc, failing to simply fork when development goals conflict, planned
esoteric-ism and/or planned obsolescence, failure to secure clientèle
data by using fully free systems (when relevant), failure to
participate-in and be-aware-of public conversations about the
underlining security of said systems (when relevant), failure to
disclose supplychain information/identities (when relevant), failure
at general transparency.

All of these things traditionally go wrong with not only companies
that use open source, but companies in-general.

Then, it truly truly dawned on me, free software needs standards
organizations as well.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom
Luke Kenneth Casson Leighton
2017-05-31 13:51:14 UTC
Permalink
Raw Message
Post by John Luke Gibson
Then, it truly truly dawned on me, free software needs standards
organizations as well.
or something like that.. yeah.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-net
John Luke Gibson
2017-05-31 17:05:51 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Then, it truly truly dawned on me, free software needs standards
organizations as well.
or something like that.. yeah.
It would a great opportunity for projects like blender and gimp, that
a company could use a certification mark that basically says "they
contributed; there were no gpl violations; they made themselves
available on mailing lists; they didn't bumble around with the
software instead of asking for help; they were transparent with the
public about anything we would find ethically-questionable;" etcetera
etcetera. That mark would like include a QR code which people could
check the status and make sure a physically printed mark hasn't been
revoked after printing. And, their could be regular transparent
royalty/inspection fee for as long as the company wants that mark to
have an active status.

It's brilliant!

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.
Luke Kenneth Casson Leighton
2017-05-31 17:17:34 UTC
Permalink
Raw Message
huh. hmmm, if it's ok with you i might run that by dr stallman, see
what he thinks.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Then, it truly truly dawned on me, free software needs standards
organizations as well.
or something like that.. yeah.
It would a great opportunity for projects like blender and gimp, that
a company could use a certification mark that basically says "they
contributed; there were no gpl violations; they made themselves
available on mailing lists; they didn't bumble around with the
software instead of asking for help; they were transparent with the
public about anything we would find ethically-questionable;" etcetera
etcetera. That mark would like include a QR code which people could
check the status and make sure a physically printed mark hasn't been
revoked after printing. And, their could be regular transparent
royalty/inspection fee for as long as the company wants that mark to
have an active status.
It's brilliant!
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co
John Luke Gibson
2017-05-31 22:35:53 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
huh. hmmm, if it's ok with you i might run that by dr stallman, see
what he thinks.
That'd be awesome; be awesomer if you mentioned me ('d love to win zeh
brownie points xS)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.c
Luke Kenneth Casson Leighton
2017-06-05 04:57:04 UTC
Permalink
Raw Message
On Wed, May 31, 2017 at 6:17 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
huh. hmmm, if it's ok with you i might run that by dr stallman, see
what he thinks.
ok, so i spoke to dr stallman, it took me a while to get across the
idea, and after clarifying it he said, *in effect*, "please could you
write up some developer best practices as long as every GNU Project
would automatically conform to them". he didn't exactly say that, so
please do not quote me on it.

the starting point should be to take this "list of project *SERVICES*
offered to the GNU project"
https://www.gnu.org/software/devel.en.html

and turn it into a list of *GENERAL* project *RECOMMENDATIONS*, using
the GNU server services as... like... the "Gold Standard".

the one thing that is missing from this list is a "Charter" - like
how the Apache Software Foundation has a Charter. i am not entirely
sure what to advise / do on that. over the past 20+ years i have
witnessed many high-profile projects treat good people in some pretty
horrible ways - not once and not on just the one project but many many
times.

the Apache Software Foundation on the other hand, whilst they have had
problems, their Charter has allowed them to (formally) keep things
"civil", including being able to remove a project leader who clearly
did not understand the harm he was causing to the project, through his
actions.

also worthwhile considering is adding the recommendation for
developers to take the "Hippocratic Oath for Software Engineers".

http://farmerandfarmer.org/medicine/printable.html

the nice thing about that oath is that it can just be added simply to
make people aware of it... *without* actually requiring that they take
it.

anyway i have started a page here in order to coordinate ideas and the
actual proposal:

http://rhombus-tech.net/proposed_best_practices/

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to a
John Luke Gibson
2017-06-05 21:47:35 UTC
Permalink
Raw Message
Alrightie~!

Foremost, since "existing" free software and cultural works aren't
likely to be sold, I think a libre software standards organization
wouldn't certify individual works or pieces of code, so much as
projects as a whole including roles performed by non-developers

Version control is almost ubiquitously used for source code, to the
point it should hardly need mentioned; however very rarely are
non-source project files, such as .blend files, collaboratively
designed this way. I don't think people are unwilling to use version
control in this way, rather they just don't think of it since most
artists aren't developers and art has been digitally designed for much
longer than version control systems have been easy to use. So I think
uploading files to repository and saving changes as commits, would be
a good 'non-developer' "best practice" to apply to a software
certification standard.

Anyways, developer 'best practices'.
Having idle hands study and document code, particularly esoteric parts
or parts they, the contributors, are unfamiliar with (so they can
learn it*). Generally, the instinct we are taught from criticisms of
our artwork, is that 'if we can't do something well, it's best not to
do it at all', however with our version control systems generally the
opposite is much more likely true, leaving room also for the hopefully
soon to be colloquial: "if a task seems too easy, it is best leave it
for someone else more novice; if a task seems too difficult, it is
best to do it sloppily, so someone else won't have to do it start from
nothing". So I think doing the best we possibly can do to develop the
worst code and worst documentation we possibly can, (xD) is another
good developer 'best practice'.

Most of us know it's not uncommon for very large projects to receive
access to proprietary source code under NDA, just to mod it**.
Likewise libre software is often perceived as insufficient as-is,
however proprietary software can be close enough that it is more
practical. In these cases, we need to respect reality, however also
ensure all is carefully weighed. The biggest pitfall is looking at all
the forks, addons, and extensions, then also looking at what you would
like to do that one can't with proprietary software out of the box.
Whilest being careful not to berate preferences, looking at how
modifiable the base program is and what it could accomplish rather
than what it can accomplish, is an important thing to make sure both
project's developer's and non-developer's occasionally remember to do.
So, considering what we could do more proportionally with what we can
do, is an important developer and non-developer 'best practice',
especially since as least occasionally they'll make one of their
could-do'es someone else's can-do.

Another practice that kindof ties in with the other one, and an often
unsung aim of the GNU project as a whole, is make programming easier.
Occasionally, a project will have extra resources or
volunteers/contributors than their described roadmap warrants. Not
always is this obvious from the beginning when it does happen. In
fact, usually it isn't till the end that it becomes apparent. The
ideal would be say 'even if proprietary software is more practical,
use/extend free software for the benefit of everyone when you have the
resource', but the reality is very rarely will you know you have the
resources until it's far too late. Instead, a good programming
practice might be to use the extra resources to modify the language
itself or some api to make the code smaller. We all should know line
counting is a trap, but we should also know we are more likely to read
a pamphlet than a book. So, it should be a good developer 'best
practice' should be to use extra resources at the end to make your
code intuitive and concise, and to fork others so hopefully
adaptations to libraries and compilers that make your code more
concise and intuitive get upstream.

This is just a rough start, but I wanted to post it here and get
feedback before putting it on the wiki.

I really like the analogy of medicine to software development,
particularly the use of the Hippocratic Oath as a point of reference.
I was looking at the 'original' oath, and there is an interesting
intersection with the morals of free software. Take a look at this:

"to impart precept, oral instruction, and all other instruction to my
own [kids], the [kids] of my teacher, and to indentured pupils who
have taken the physician’s oath, but to nobody else."***

That last bit of 'teaching no one else' is a little tongue-and-cheek
for the free software movement xD But, still, it has this aura of
freedom of information that's interesting for ancients.

In fact most of the last two and the first two clauses, mutually apply
to software.
I'm the artistic type who would take the original oath and edit it to
apply to software****.


*

**

*** https://en.wikipedia.org/wiki/Hippocratic_Oath#Text_of_the_oath
**** https://en.wikipedia.org/wiki/Intertextuality
Post by Luke Kenneth Casson Leighton
On Wed, May 31, 2017 at 6:17 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
huh. hmmm, if it's ok with you i might run that by dr stallman, see
what he thinks.
ok, so i spoke to dr stallman, it took me a while to get across the
idea, and after clarifying it he said, *in effect*, "please could you
write up some developer best practices as long as every GNU Project
would automatically conform to them". he didn't exactly say that, so
please do not quote me on it.
the starting point should be to take this "list of project *SERVICES*
offered to the GNU project"
https://www.gnu.org/software/devel.en.html
and turn it into a list of *GENERAL* project *RECOMMENDATIONS*, using
the GNU server services as... like... the "Gold Standard".
the one thing that is missing from this list is a "Charter" - like
how the Apache Software Foundation has a Charter. i am not entirely
sure what to advise / do on that. over the past 20+ years i have
witnessed many high-profile projects treat good people in some pretty
horrible ways - not once and not on just the one project but many many
times.
the Apache Software Foundation on the other hand, whilst they have had
problems, their Charter has allowed them to (formally) keep things
"civil", including being able to remove a project leader who clearly
did not understand the harm he was causing to the project, through his
actions.
also worthwhile considering is adding the recommendation for
developers to take the "Hippocratic Oath for Software Engineers".
http://farmerandfarmer.org/medicine/printable.html
the nice thing about that oath is that it can just be added simply to
make people aware of it... *without* actually requiring that they take
it.
anyway i have started a page here in order to coordinate ideas and the
http://rhombus-tech.net/proposed_best_practices/
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme
Luke Kenneth Casson Leighton
2017-06-06 04:51:33 UTC
Permalink
Raw Message
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by John Luke Gibson
Alrightie~!
Foremost, since "existing" free software and cultural works aren't
likely to be sold, I think a libre software standards organization
wouldn't certify individual works or pieces of code, so much as
projects as a whole including roles performed by non-developers
indeed.
Post by John Luke Gibson
Version control is almost ubiquitously used for source code, to the
point it should hardly need mentioned;
absolutely dead-wrong. it needs *absolutely* to be clearly defined.
the practice of saying "well everyone does it so we don't need to take
special note of it" is how, historically, utterly valuable knowledge
has been lost through the ages.

a good example is all the folk tunes of medieval times: *nobody knows
them any more* because quotes everybody knew them quotes so NOBODY
WROTE THEM DOWN.

so no, john: it *is* critical that everything that's ubiquitous and
quotes obvious quotes be formally documented.

then, not least, you will discover that actually, everybody uses
github "by default".... which, when you read (and take) the software
engineer's hippocratic oath you find that it's very hard to honour
that oath and use github at the same time.
Post by John Luke Gibson
however very rarely are
non-source project files, such as .blend files, collaboratively
designed this way. I don't think people are unwilling to use version
control in this way, rather they just don't think of it since most
artists aren't developers and art has been digitally designed for much
longer than version control systems have been easy to use. So I think
uploading files to repository and saving changes as commits, would be
a good 'non-developer' "best practice" to apply to a software
certification standard.
if they're "developing" then by definition they *are* developers,
whether they think of themselves that way or not. in the hippocratic
oath (both the original and the engineering version i found) it
mentions that both practices combine art *and* science.
Post by John Luke Gibson
Anyways, developer 'best practices'.
Having idle hands study and document code, particularly esoteric parts
or parts they, the contributors, are unfamiliar with (so they can
learn it*). Generally, the instinct we are taught from criticisms of
our artwork, is that 'if we can't do something well, it's best not to
do it at all', however with our version control systems generally the
opposite is much more likely true, leaving room also for the hopefully
soon to be colloquial: "if a task seems too easy, it is best leave it
for someone else more novice; if a task seems too difficult, it is
best to do it sloppily, so someone else won't have to do it start from
nothing". So I think doing the best we possibly can do to develop the
worst code and worst documentation we possibly can, (xD) is another
good developer 'best practice'.
ok... there are two different definitions of "developer best
practices". the above goes into detail on how an individual developer
should best carry out the development process; the document that i
would like to see written is one which helps people (covering both
users *and* developers) to work as TEAMS. what INFRASTRUCTURE and
general mind-set will help people to work together.

not "as a developer we must apply Agile or other Methodology". that's
not appropriate: we have no proof that Agile or other "Methodology"
will be more effective than any other, and i don't believe it to be
appropriate for us to even research that.
Post by John Luke Gibson
Most of us know it's not uncommon for very large projects to receive
access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups,
so this is not a concern.
Post by John Luke Gibson
Likewise libre software is often perceived as insufficient as-is,
however proprietary software can be close enough that it is more
practical. In these cases, we need to respect reality, however also
ensure all is carefully weighed. The biggest pitfall is looking at all
the forks, addons, and extensions, then also looking at what you would
like to do that one can't with proprietary software out of the box.
Whilest being careful not to berate preferences, looking at how
modifiable the base program is and what it could accomplish rather
than what it can accomplish, is an important thing to make sure both
project's developer's and non-developer's occasionally remember to do.
So, considering what we could do more proportionally with what we can
do, is an important developer and non-developer 'best practice',
especially since as least occasionally they'll make one of their
could-do'es someone else's can-do.
i don't understand where you're going with this. what is the main point?
Post by John Luke Gibson
Another practice that kindof ties in with the other one, and an often
unsung aim of the GNU project as a whole, is make programming easier.
to make *programming* easier or to make *collaboration* easier?
Post by John Luke Gibson
Occasionally, a project will have extra resources or
volunteers/contributors than their described roadmap warrants. Not
always is this obvious from the beginning when it does happen. In
fact, usually it isn't till the end that it becomes apparent. The
ideal would be say 'even if proprietary software is more practical,
use/extend free software for the benefit of everyone when you have the
resource', but the reality is very rarely will you know you have the
resources until it's far too late. Instead, a good programming
practice might be to use the extra resources to modify the language
itself or some api to make the code smaller. We all should know line
counting is a trap, but we should also know we are more likely to read
a pamphlet than a book. So, it should be a good developer 'best
practice' should be to use extra resources at the end to make your
code intuitive and concise, and to fork others so hopefully
adaptations to libraries and compilers that make your code more
concise and intuitive get upstream.
again, i feel that it is not appropriate to tell people these kinds
of things, as it would be a restriction on what they do and learn.
counter-example: some projects *have* to have a large code-base, by
definition of their goals and scope.
Post by John Luke Gibson
This is just a rough start, but I wanted to post it here and get
feedback before putting it on the wiki.
wrong focus / direction, john.

the first step *really is* to quite literally copy - verbatim - the
gnu devel.html page and "generify" it.

where it says "we recommend savannah" put instead "we recommend the
use of a Libre Hosting Service which has a minimum criteria of an A,
as defined by the FSF's Hosting Criteria".

where it says "we recommend mailing lists on gnu.org" put instead "we
recommend the use of software libre hosted mailing lists". a later
revision should go into further detail as to *why* "announce",
"users", "dev" etc. is recommended.

etc. etc.

this is a completely different focus from advising people on *coding
methodologies*.
Post by John Luke Gibson
I really like the analogy of medicine to software development,
particularly the use of the Hippocratic Oath as a point of reference.
I was looking at the 'original' oath, and there is an interesting
intersection with the morals of free software.
indeed there is.... but that is simply not understood by the majority
of people associated with free software. you can usually tell who
they are because they use the words "open" and "source".

which is why i feel it should be part of the recommendations. again:
it is one of those things which is never really discussed because
those people who *do* understand it just... follow it (without talking
about it) and that means that those people who *don't* understand get
really *really* confused and misled.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
S
John Luke Gibson
2017-06-06 12:01:02 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
"well everyone does it so we don't need to take
special note of it" is how, historically, utterly valuable knowledge
has been lost through the ages.
That's a very valid point. However I think the point of a standards
organization should be to spread information about their standards
that aren't widely or commonly known and it highly useful. Ultimately
there will be some very new people looking for information, and for
them knowing about the usefulness of version control would be
important. Again, though, if only mundane things like that were taken
on as a core tenets, I don't think anyone would take the organization
seriously.
Post by Luke Kenneth Casson Leighton
then, not least, you will discover that actually, everybody uses
github "by default".... which, when you read (and take) the software
engineer's hippocratic oath you find that it's very hard to honour
that oath and use github at the same time.
I don't think there is much wrong the way github is designed, so much
as it's economic model for sustaining itself. It requires closed
source software development to survive. That's naughty.
Post by Luke Kenneth Casson Leighton
if they're "developing" then by definition they *are* developers,
whether they think of themselves that way or not. in the hippocratic
oath (both the original and the engineering version i found) it
mentions that both practices combine art *and* science.
We really don't want to throw around that label, it'll be
controversial if we do.
The overall point I was try to make in that clause is, 'everyone
thinks to collaborate on source, but no one thinks to collaborate on
assets'.

I don't think many realize it's possible for 100+ people to
collaborate on a single drawing using version control and effective
curation. It'd be absurd, but it'd be possible. As it stands, most
assets are designed entirely by a single person, because people don't
realize the collaboration tools and methodologies out there.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
"if a task seems too easy, it is best leave it
for someone else more novice; if a task seems too difficult, it is
best to do it sloppily, so someone else won't have to do it start from
nothing". So I think doing the best we possibly can do to develop the
worst code and worst documentation we possibly can, (xD) is another
good developer 'best practice'.
ok... there are two different definitions of "developer best
practices". the above goes into detail on how an individual developer
should best carry out the development process; the document that i
would like to see written is one which helps people (covering both
users *and* developers) to work as TEAMS. what INFRASTRUCTURE and
general mind-set will help people to work together.
not "as a developer we must apply Agile or other Methodology". that's
not appropriate: we have no proof that Agile or other "Methodology"
will be more effective than any other, and i don't believe it to be
appropriate for us to even research that.
Hmm.. *searches 'Agile development methodology'* I agree.
I always hated those cause they felt like a tight 'inside of the
inside box' structure.
What I'm suggesting here is Definitely a collaborative methodology and
-I think- a pretty abstract and general one.

Essentially the point is, in a large open development, odds are there
will be people more senior and more novice to you. To develop the most
difficult code 'for you' possible, we prioritize personal development
over project development. I think that's a pretty solid general rule.
If the code is really sincerely important, someone will clean up your
mistakes and use your successes.

Yes, I the principle is of focusing on the individual, but there's
nothing more important to remind a collective to do.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Most of us know it's not uncommon for very large projects to receive
access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups,
so this is not a concern.
For one,
I think that's problematic. There are some projects to advance
humanity stuck in closed-development, sometimes for honorable
not-profit-motivations. Take radar development for example. Or, AI
development. The last one is a hot-button topic, but I think AI
development has to be relegated to those careful to avoid AI hating
us.

For two,
Some projects have a goal besides open source or profit. I really like
Star Citizen*. They show us EVERYTHING, except their source. Obviously
they can't because what they are trying to do, Requires modding closed
source software. It's very open, even if it's very closed. If an
organization like that wants to contribute to the development of some
libre software they are borrowing, we should recognize them. Maybe if
we buildup a strong rapport with them, they'll release their game into
the public domain one day just to say 'thankz, for all the lulz'.

* https://robertsspaceindustries.com/about-the-game
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision
not to use kicad, there will be many incidences where open projects
need to decide between modding-up open software or using proprietary
software. Occasionally, the former is just not practical.

A standards organization, would do best to make sure they weighed both
possibilities realistically and didn't just assume one or the other
was more practical.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Another practice that kindof ties in with the other one, and an often
unsung aim of the GNU project as a whole, is make programming easier.
to make *programming* easier or to make *collaboration* easier?
Both. Most languages today are pretty esoteric, even today. And, the
problem isn't so much with the docs, as these languages were designed
for people that already new another language equally esoteric, etc.

I would think Lisp's resurgence (as well as developing Guile) is a
demonstration of GNU trying to break away from that paradigm.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
[blah blah blah about making programming easier]
again, i feel that it is not appropriate to tell people these kinds
of things, as it would be a restriction on what they do and learn.
counter-example: some projects *have* to have a large code-base, by
definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is.
I only mean concise when it means intuitive.
If a projects roadmap demands a large code base that is
highly-esoteric and unintuitive, then that exhibits fault in the
underlying language.

I'm not suggesting any project change to prioritize this. To the
contrary, I think I was quite clear: a project should only dedicate
'extra' resources to this type of endeavor.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
This is just a rough start, but I wanted to post it here and get
feedback before putting it on the wiki.
wrong focus / direction, john.
the first step *really is* to quite literally copy - verbatim - the
gnu devel.html page and "generify" it.
No one will want to advice from an organization that bible thumps the
same points, much less financially support them in exchange for doing
so.
I think it is important to develop universally acceptable principles
(i.e. things people find interesting to hear, but not necessarily want
to hear) which are useful.
Post by Luke Kenneth Casson Leighton
where it says "we recommend savannah" put instead "we recommend the
use of a Libre Hosting Service which has a minimum criteria of an A,
as defined by the FSF's Hosting Criteria".
Eh, 0-to-1. Redundancy is nice, but can be confusing. I think it would
probably more effective to just let any libre hosting service which
has criteria A call themselves savanna, but I don't think were a
person stores their code should be a huge point of tension.

Ultimately, in a 0-to-1 paradigm, we are trying to develop closer to
perfection, rather than closer to more competitive. Having multiple
types of libre hosting services is like having multiple
https://en.wikipedia.org/wiki/WP:POVFORK 'es.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send lar
Hendrik Boom
2017-06-06 14:20:42 UTC
Permalink
Raw Message
Post by John Luke Gibson
Both. Most languages today are pretty esoteric, even today. And, the
problem isn't so much with the docs, as these languages were designed
for people that already new another language equally esoteric, etc.
I would think Lisp's resurgence (as well as developing Guile) is a
demonstration of GNU trying to break away from that paradigm.
Racket is a rather interesting variant of Scheme. Aside from having
good tutorials and documentation, it explicitly allows mixed-language
development. In fact, the first line of a Racket module usually
states which language to use for the rest. And Racket has tools
for defining alternative syntax and/or semantics.
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
[blah blah blah about making programming easier]
again, i feel that it is not appropriate to tell people these kinds
of things, as it would be a restriction on what they do and learn.
counter-example: some projects *have* to have a large code-base, by
definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is.
I only mean concise when it means intuitive.
If a projects roadmap demands a large code base that is
highly-esoteric and unintuitive, then that exhibits fault in the
underlying language.
Racket's language-definition tool can be used to shorten notation
within a large program, and also to define completely new languages.

For example, one of the languages so implemented is Algol 60.

Another is Scribble, a document compiler. Being based on Racket, it's
possible to use arbitrary Scheme code in generating your document,
should you choose to.

-- hendrik
Post by John Luke Gibson
I'm not suggesting any project change to prioritize this. To the
contrary, I think I was quite clear: a project should only dedicate
'extra' resources to this type of endeavor.
There's one case in which a project decided they needed a scripting
language, and they chose Gambit, a Scheme dialect that compiles to C
or C++.

After they installed it, they discovered that it was often easier to
add features in the scripting language than in the original C++ code.

Then they disovered that fixing bugs could often be done by replacing
buggy C++ code by Scheme code.

After a few years, the codebase shrank from about 200,000 lines of
code to about 30,000. (I'm not sure of the exact numbers, but they
were of these orders of magnitude.)

-- hendrik

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp
John Luke Gibson
2017-06-06 15:41:49 UTC
Permalink
Raw Message
Post by Hendrik Boom
After a few years, the codebase shrank from about 200,000 lines of
code to about 30,000. (I'm not sure of the exact numbers, but they
were of these orders of magnitude.)
Dats bootiful (ノ◕ヮ◕)ノ*:・゚✧
Post by Hendrik Boom
Post by John Luke Gibson
Both. Most languages today are pretty esoteric, even today. And, the
problem isn't so much with the docs, as these languages were designed
for people that already new another language equally esoteric, etc.
I would think Lisp's resurgence (as well as developing Guile) is a
demonstration of GNU trying to break away from that paradigm.
Racket is a rather interesting variant of Scheme. Aside from having
good tutorials and documentation, it explicitly allows mixed-language
development. In fact, the first line of a Racket module usually
states which language to use for the rest. And Racket has tools
for defining alternative syntax and/or semantics.
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
[blah blah blah about making programming easier]
again, i feel that it is not appropriate to tell people these kinds
of things, as it would be a restriction on what they do and learn.
counter-example: some projects *have* to have a large code-base, by
definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is.
I only mean concise when it means intuitive.
If a projects roadmap demands a large code base that is
highly-esoteric and unintuitive, then that exhibits fault in the
underlying language.
Racket's language-definition tool can be used to shorten notation
within a large program, and also to define completely new languages.
For example, one of the languages so implemented is Algol 60.
Another is Scribble, a document compiler. Being based on Racket, it's
possible to use arbitrary Scheme code in generating your document,
should you choose to.
-- hendrik
Post by John Luke Gibson
I'm not suggesting any project change to prioritize this. To the
contrary, I think I was quite clear: a project should only dedicate
'extra' resources to this type of endeavor.
There's one case in which a project decided they needed a scripting
language, and they chose Gambit, a Scheme dialect that compiles to C
or C++.
After they installed it, they discovered that it was often easier to
add features in the scripting language than in the original C++ code.
Then they disovered that fixing bugs could often be done by replacing
buggy C++ code by Scheme code.
After a few years, the codebase shrank from about 200,000 lines of
code to about 30,000. (I'm not sure of the exact numbers, but they
were of these orders of magnitude.)
-- hendrik
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Luke Kenneth Casson Leighton
2017-06-06 17:47:48 UTC
Permalink
Raw Message
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
"well everyone does it so we don't need to take
special note of it" is how, historically, utterly valuable knowledge
has been lost through the ages.
That's a very valid point. However I think the point of a standards
organization should be to spread information about their standards
that aren't widely or commonly known and it highly useful. Ultimately
there will be some very new people looking for information, and for
them knowing about the usefulness of version control would be
important. Again, though, if only mundane things like that were taken
on as a core tenets, I don't think anyone would take the organization
seriously.
Post by Luke Kenneth Casson Leighton
then, not least, you will discover that actually, everybody uses
github "by default".... which, when you read (and take) the software
engineer's hippocratic oath you find that it's very hard to honour
that oath and use github at the same time.
I don't think there is much wrong the way github is designed, so much
as it's
... you mean the word "its", not the two words "it" and "is" which
are abbreviated as "it apostrophe s".
Post by John Luke Gibson
economic model for sustaining itself. It requires closed
source software development to survive. That's naughty.
it does deeper than that, in a very seductive and insidious way.
what is the primary focus - what does github drive people to do, that
distinguishes it from sourceforge, savannah, alioth, codeforge and
other group collaboration systems?
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
if they're "developing" then by definition they *are* developers,
whether they think of themselves that way or not. in the hippocratic
oath (both the original and the engineering version i found) it
mentions that both practices combine art *and* science.
We really don't want to throw around that label,
what ambiguous concept are you referring to with the word "that"
which has not been made explicitly clear? there are about 40 words in
the paragraph that you are referring to: i have no idea which one the
word "that" refers to.
Post by John Luke Gibson
Essentially the point is, in a large open development, odds are there
will be people more senior and more novice to you. To develop the most
difficult code 'for you' possible, we prioritize personal development
over project development. I think that's a pretty solid general rule.
If the code is really sincerely important, someone will clean up your
mistakes and use your successes.
not if they are there to further their own personal agenda because
there is no "Charter" to keep them goal-focussed, they won't. there
are a number of large software libre projects where individuals have,
over time, used their technical expertise to become the most vicious,
horrible, deceptive bullies you will ever encounter in a technical
environment. their peers become *so afraid* to do something about it
that these people *remain* in power, abusing others whenever the
opportunity presents itself.

this is something that i have encountered not just once but
*multiple* times, in several extremely high-profile strategic software
libre projects.
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Most of us know it's not uncommon for very large projects to receive
access to proprietary source code under NDA, just to mod it**.
we are automatically excluding advice to proprietary software groups,
so this is not a concern.
For one,
I think that's problematic. There are some projects to advance
humanity stuck in closed-development, sometimes for honorable
not-profit-motivations. Take radar development for example. Or, AI
development. The last one is a hot-button topic, but I think AI
development has to be relegated to those careful to avoid AI hating
us.
true.

however - and i am applying the "Bill of Ethics" here - the Bill of
Ethics is very clear as to what to do in these situations.
"Creativity" is defined as "resources times intelligence". therefore,
if someone is using Creativity for unethical purposes (where in this
case we *know* that proprietary software is unethical.... let's not
argue about that), then there are two options to ETHICALLY undermine
their unethical objective:

(1) reduce their access to resources
(2) reduce their access to intelligence enhancement.

now, in the process of writing a standard, we do not have the means
to (directly) reduce the amount of resources that unethical
proprietary software teams have access to, but we *can* reduce their
access to intelligence enhancement... by *SPECIFICALLY* designing the
standard so that it targets ETHICAL software development, and that
means LIBRE SOFTWARE ONLY.

i am NOT going to aid or assist unethical practices - period, luke.
i will NOT be involved in ANY WAY in the development of a standard
which could be utilised for the advancement, augmentation,
acceleration or improvement of unethical software development
practices, and that really is the end of the matter.
Post by John Luke Gibson
* https://robertsspaceindustries.com/about-the-game
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision
not to use kicad,
that's mainly to do with the fact that it's shit software. sadly,
it's only when you've utilised well-written proprietary software that
you realise quite how hostile kicad actually is to getting the job
done. i'm not very happy about that, but it turns out that i am not
the only person to have tried.
Post by John Luke Gibson
there will be many incidences where open projects
need to decide between modding-up open software or using proprietary
software. Occasionally, the former is just not practical.
A standards organization, would do best to make sure they weighed both
possibilities realistically and didn't just assume one or the other
was more practical.
no. sorry. i cannot be involved in anything which is unethical.
that is ABSOLUTE and non-negotiable. the consequences for me to be
involved in anything that is unethical are too disastrous to
contemplate.

writing a high-profile standard (which is to be published by the FSF)
that helps proprietary software to improve its success would be
totally unethical.
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
again, i feel that it is not appropriate to tell people these kinds
of things, as it would be a restriction on what they do and learn.
counter-example: some projects *have* to have a large code-base, by
definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is.
I only mean concise when it means intuitive.
If a projects roadmap demands a large code base that is
highly-esoteric and unintuitive, then that exhibits fault in the
underlying language.
no it does not. certain tasks *require* specific languages. for
example: the linux kernel *requires* that you use assembler and c.
UNDER NO CIRCUMSTANCES is c++ permitted to be utilised.

likewise, python is also developed in c. you can look up how pypy
has been getting on, to find out how unsuccessful it was to attempt to
implement python in anything other than c.

also you can look up the efforts by the samba team to abandon c and
to try to write parts of samba 4 in python. this was also a
spectacular and long-drawn-out failure.

in the case of samba, it has to be realised that samba is an
amalgamation of something like over TEN different network protocols,
at least FOUR separate and distinct RPC mechanisms, and over FORTY
separate and distinct inter-related services! the complexity of the
endeavour is just... astounding.

when samba 4 was first announced i thought it was a joke. they
intended to implement not only the MSRPC services, but also to
implement their own Kerberos Server and LDAP server. what the FUCK??
Heimdal is a QUARTER of a MILLION lines of code on its own. openldap
is likewise similarly large... and samba is probably getting on for
HALF a million lines of code WITHOUT these projects added to it!

they're completely out of their MINDS if they think that's going to
work... or be accepted by sysadmins... and guess what? 10 years later
they still hadn't finished, and 15 years later they'd driven pretty
much every single large Enterprise (that had deployed samba for years)
right back to Windows NT Server!


the reason i am mentioning the example of Samba is because despite
following what is known to be "best software libre hosting practices",
they DO NOT HAVE A CHARTER and the developers *certainly* do not sign
up to the Software Engineer's variant of the Hippocratic Oath.

there is more, but i will relay that another time.
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
This is just a rough start, but I wanted to post it here and get
feedback before putting it on the wiki.
wrong focus / direction, john.
the first step *really is* to quite literally copy - verbatim - the
gnu devel.html page and "generify" it.
No one will want to advice from an organization that bible thumps the
same points, much less financially support them in exchange for doing
so.
do you understand why those software development practices (with the
addition of a Charter) listed on the gnu devel page are so effective?

ok let's go over it.

what are the defining (common) characteristics of the following
high-profile long-running strategic free software projects, and, of
the superset of those combined characteristics, which projects LACK
those characteristics?

* Samba
* Wine
* ReactOS
* Python
* Perl
* Exim4
* sendmail
* Linux Kernel
* GNU Projects (as defined by that devel.html page)
* Webkit
* Blink
* Firefox
* Debian
* Ubuntu
* Slackware
* systemd
* mysqldb
* mariadb
* openoffice
* libreoffice
* X11
* Xorg
* Kerberos
* Heimdal
* OpenLDAP

make a list of all the things that those projects have in common,
then, after making that list, identify the things on that list which
individual projects *do not* have.

i will then provide you with some illustrations of events that have
occurred within those teams which have been extremely detrimental to
the users of those packages.

we will then cross-reference the things that are MISSING from those
projects with the detrimental consequences, to see if there is any
correlation.

if you can think of any other long-standing high-profile projects
which should be on that list, feel free to add them.
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
where it says "we recommend savannah" put instead "we recommend the
use of a Libre Hosting Service which has a minimum criteria of an A,
as defined by the FSF's Hosting Criteria".
Eh, 0-to-1.
i don't understand this colloquial turn of phrase. anyway it is not
important: going through the list above is much more important.
Post by John Luke Gibson
I don't think were a
person stores their code should be a huge point of tension.
i know you don't. so i therefore need to walk you through the
process of understanding why it is, in fact, one of *the* most
important factors (in amongst many of roughly equal priority). going
through that list, above, will help to do that.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp
d***@mail.com
2017-06-11 20:50:50 UTC
Permalink
Raw Message
On Tue, 6 Jun 2017 18:47:48 +0100
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
"well everyone does it so we don't need to take
special note of it" is how, historically, utterly valuable knowledge
has been lost through the ages.
That's a very valid point. However I think the point of a standards
organization should be to spread information about their standards
that aren't widely or commonly known and it highly useful. Ultimately
there will be some very new people looking for information, and for
them knowing about the usefulness of version control would be
important. Again, though, if only mundane things like that were taken
on as a core tenets, I don't think anyone would take the organization
seriously.
Post by Luke Kenneth Casson Leighton
then, not least, you will discover that actually, everybody uses
github "by default".... which, when you read (and take) the software
engineer's hippocratic oath you find that it's very hard to honour
that oath and use github at the same time.
I don't think there is much wrong the way github is designed, so much
as it's
<snip>
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
economic model for sustaining itself. It requires closed
source software development to survive. That's naughty.
it does deeper than that, in a very seductive and insidious way.
what is the primary focus - what does github drive people to do, that
distinguishes it from sourceforge, savannah, alioth, codeforge and
other group collaboration systems?
I give up. Why do some people dislike github or sourceforge?
This is at least the third mailing list in which I've seen discontent
without a reason given.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
* https://robertsspaceindustries.com/about-the-game
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
[blah blah, about choosing between proprietary and free software]
i don't understand where you're going with this. what is the main point?
Most projects will be hardware projects and, like with your decision
not to use kicad,
that's mainly to do with the fact that it's s*** software. sadly,
it's only when you've utilised well-written proprietary software that
you realise quite how hostile kicad actually is to getting the job
done. i'm not very happy about that, but it turns out that i am not
the only person to have tried.
Just out of interest, not that I can do something about it *now*, is there
any sort of list of "Things-that-a-kicad-or-clone-aught-to-do"?
People can't fix or add what they don't know that they are missing and I,
for one, would not ever use, or if I did not read this mailing list, know
the name of, a "better" proprietary alternative.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
there will be many incidences where open projects
need to decide between modding-up open software or using proprietary
software. Occasionally, the former is just not practical.
A standards organization, would do best to make sure they weighed both
possibilities realistically and didn't just assume one or the other
was more practical.
no. sorry. i cannot be involved in anything which is unethical.
that is ABSOLUTE and non-negotiable. the consequences for me to be
involved in anything that is unethical are too disastrous to
contemplate.
writing a high-profile standard (which is to be published by the FSF)
that helps proprietary software to improve its success would be
totally unethical.
???
Why not start with recommending them to make their software open source?
Or set up a time table with the sources being released when the project
has reached a certain reasonable financial goal or age.
Age was used to determine when to release at least warzone2100, firefox,
and X.
Money wise, a company could say that after they made, say 2X the amount
of their costs for producing the SW, then the users have "Bought the
code".
You have to start converting the closed source SW fanboys from somewhere.
Post by Luke Kenneth Casson Leighton
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
again, i feel that it is not appropriate to tell people these kinds
of things, as it would be a restriction on what they do and learn.
counter-example: some projects *have* to have a large code-base, by
definition of their goals and scope.
I recognize that intuitive isn't always concise, but often it is.
I only mean concise when it means intuitive.
If a projects roadmap demands a large code base that is
highly-esoteric and unintuitive, then that exhibits fault in the
underlying language.
no it does not. certain tasks *require* specific languages. for
example: the linux kernel *requires* that you use assembler and c.
UNDER NO CIRCUMSTANCES is c++ permitted to be utilised.
likewise, python is also developed in c. you can look up how pypy
has been getting on, to find out how unsuccessful it was to attempt to
implement python in anything other than c.
also you can look up the efforts by the samba team to abandon c and
to try to write parts of samba 4 in python. this was also a
spectacular and long-drawn-out failure.
in the case of samba, it has to be realised that samba is an
amalgamation of something like over TEN different network protocols,
at least FOUR separate and distinct RPC mechanisms, and over FORTY
separate and distinct inter-related services! the complexity of the
endeavour is just... astounding.
when samba 4 was first announced i thought it was a joke. they
intended to implement not only the MSRPC services, but also to
implement their own Kerberos Server and LDAP server. what the FUCK??
Heimdal is a QUARTER of a MILLION lines of code on its own. openldap
is likewise similarly large... and samba is probably getting on for
HALF a million lines of code WITHOUT these projects added to it!
they're completely out of their MINDS if they think that's going to
work... or be accepted by sysadmins... and guess what? 10 years later
they still hadn't finished, and 15 years later they'd driven pretty
much every single large Enterprise (that had deployed samba for years)
right back to Windows NT Server!
the reason i am mentioning the example of Samba is because despite
following what is known to be "best software libre hosting practices",
they DO NOT HAVE A CHARTER and the developers *certainly* do not sign
up to the Software Engineer's variant of the Hippocratic Oath.
there is more, but i will relay that another time.
<snip>

If they want all that functionality, why not just utilize the already
opensource libraries for the task?
Developing everything in house seems so.... wasteful and slow.
The typical reason given is control, but if you are in control then *you
are responsible* and then and there ball gets dropped. Look at blender,
if I build with anything other than their in house copies of libraries it
SEGFAULTS when I start it up.


Thanks,
David

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac
Adam Van Ymeren
2017-06-12 19:33:38 UTC
Permalink
Raw Message
Post by d***@mail.com
I give up. Why do some people dislike github or sourceforge?
This is at least the third mailing list in which I've seen discontent
without a reason given.
Same reason they dislike proprietary software in general.

https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@
Stefan Monnier
2017-06-12 20:05:12 UTC
Permalink
Raw Message
Post by d***@mail.com
I give up. Why do some people dislike github or sourceforge?
I don't think the two are in the same category at all (and the message
to which you replied was specifically putting SourceForge in the
"other" category, indeed).

As to why some people dislike GitHub? I can't talk about other people,
but personally, I don't have much trust in it for the following reasons:
- It's a commercial company, so it has to make money somehow from its
free service.
- It doesn't publish its own code as Free Software (not even the
Javascript code you download into your browser to use the site).
- I feel a lot of pressure to use it. IOW they work hard to use the
so-called "networking effect" to pull people to their site.
The more you use it, the more you pressure other people to do likewise.
I hate this kind of centralization because it gives too much power to
a single unaccountable entity.


Stefan


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send
Tomas Nordin
2017-06-12 20:15:12 UTC
Permalink
Raw Message
Post by d***@mail.com
I give up. Why do some people dislike github or sourceforge?
This is at least the third mailing list in which I've seen discontent
without a reason given.
But reasons are given and to the point here:
https://www.fsf.org/news/gnu-releases-ethical-evaluations-of-code-hosting-services

One major problem addressed is the need to run non-free java-script to
use the service I think.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Luke Kenneth Casson Leighton
2017-06-13 02:52:07 UTC
Permalink
Raw Message
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by d***@mail.com
Just out of interest, not that I can do something about it *now*, is there
any sort of list of "Things-that-a-kicad-or-clone-aught-to-do"?
People can't fix or add what they don't know that they are missing and I,
i've tried that: reported several bugs. the developers of kicad
became entrenched in their own belief that their approach was
absolutely correct, superior, and that the problem did not exist.
after about a year, including input from other people who supported
the bugreport (also ignored), i went, "y'know what? this isn't worth
my time and effort".
Post by d***@mail.com
???
Why not start with recommending them to make their software open source?
have you seen how oracle's attitude works out? mysqldb, virtualbox,
openoffice - look up how those have been received by the software
libre community.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-n
Tzafrir Cohen
2017-06-13 09:24:38 UTC
Permalink
Raw Message
Post by d***@mail.com
I give up. Why do some people dislike github or sourceforge?
This is at least the third mailing list in which I've seen discontent
without a reason given.
Git is a nice distributed version control system. That is: each node
contains the whole archive including all of the history. No inherent
central node. So all you need to develop with it is some basic hosting,
right?

Now Github comes along and tells you: if you use git in our site, you
can have extra goodies. Pull requests work. But only so long as you are
a user of Github to begin with. If it's not in Github, it might as well
not exist.

So suddenly you have a single point of failure. This is not that good.
For instance, what if Github decides not to allow you to host your
project (for whatever legitimate reason)?

I believe most people who object using Github here object using those
extra services and not merely using Github as a git hosting service. But
this point is mostly moot, as why would you use Github and not use bug
pull requests, bug tracking etc.?

Are they evil? Certainly not. They provide a great service that people
like. We should also provide quality services / software or otherwise
people will keep depending on walled gardens.


Sourceforge has held a somewhat similar position in the past (at around
1999-2005 or so) when a large portion of the projects were hosted there
because it provided a very fine hosting facility (files, web, shell,
mailing list, tasks, and more) for free. It is no longer in that
position. One problem with it nowadays is that they have been shown to
used some non-optimal methods of getting ad money in the recent past.
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to
Luke Kenneth Casson Leighton
2017-06-18 07:05:39 UTC
Permalink
Raw Message
when i began a property business i read several books on the subject.
one of them had this wonderful quirky advice to view 100 houses before
putting any money down. i booked several viewings a day with multiple
estate agents, spending at most 10 minutes in each.

after about 80 houses i came across one that was very strange: the
price was much lower than it was for comparable houses that i'd seen.
without having viewed so many houses i would not have known this.


this same lesson i applied to the development of the EOMA68 standard.
i spent several years studying dozens of successful SoCs, looking for
the common factors between them all. several iterations had to be
made to get it right.


if we are to develop a standard i feel that it is imperative to do a
similar analysis of what constitutes a successful software libre
project.

this task isn't actually very difficult: it's almost mechanical and
purely logical. but i feel that it is very important that anything
that goes into the standard is backed up by a heck of a lot of
evidence that whatever advice is in it is demonstrably and
consistently long-term successful across not one but *multiple*
projects.

l.


On Tue, Jun 6, 2017 at 6:47 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
what are the defining (common) characteristics of the following
high-profile long-running strategic free software projects, and, of
the superset of those combined characteristics, which projects LACK
those characteristics?
* Samba
* Wine
* ReactOS
* Python
* Perl
* Exim4
* sendmail
* Linux Kernel
* GNU Projects (as defined by that devel.html page)
* Webkit
* Blink
* Firefox
* Debian
* Ubuntu
* Slackware
* systemd
* mysqldb
* mariadb
* openoffice
* libreoffice
* X11
* Xorg
* Kerberos
* Heimdal
* OpenLDAP
make a list of all the things that those projects have in common,
then, after making that list, identify the things on that list which
individual projects *do not* have.
i will then provide you with some illustrations of events that have
occurred within those teams which have been extremely detrimental to
the users of those packages.
we will then cross-reference the things that are MISSING from those
projects with the detrimental consequences, to see if there is any
correlation.
if you can think of any other long-standing high-profile projects
which should be on that list, feel free to add them.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme
Pablo Rath
2017-07-12 10:36:03 UTC
Permalink
Raw Message
On Tue, Jun 06, 2017 at 05:51:33AM +0100, Luke Kenneth Casson Leighton wrote:
...
Post by Luke Kenneth Casson Leighton
the first step *really is* to quite literally copy - verbatim - the
gnu devel.html page and "generify" it.
where it says "we recommend savannah" put instead "we recommend the
use of a Libre Hosting Service which has a minimum criteria of an A,
as defined by the FSF's Hosting Criteria".
where it says "we recommend mailing lists on gnu.org" put instead "we
recommend the use of software libre hosted mailing lists". a later
revision should go into further detail as to *why* "announce",
"users", "dev" etc. is recommended.
etc. etc.
As it seems to me the above points are done. Thank you Luke for
fixing my mishappened sentence.
There is now a point for version control, mailing lists and web pages at
the wiki (http://rhombus-tech.net/proposed_best_practices/).
Regarding the goal of a general standard for libre projects I don't
think it is necessary to cover the quite specific further points of the
gnu devel.html page: "FTP", "Login accounts", "Hydra: Continuous builds and portability
testing" and "platform-testers: Manual portability testing".

I have read a good part of the Maintainer's Guide:
https://www.gnu.org/prep/maintain/maintain.txt
and wonder how to best incorporate it into the draft for best practices.
For example from gnu devel.html page we took the point about web pages
and generalised it: "we recommend to
host the webpages for the project using resources that meet the FSF's
Hosting Criteria"
Chapter 12 Web Pages of the Maintainer's Guide covers a lot of details.

Some questions:
Has anyone else started to work on it (offline)?
How long shall the first draft of the standard be (e.g. 10 pages, 100 pages, as long as
necessary)?

As you can see I am looking for guidance and some kind of roadmap to
prevent working in the wrong direction.

kind regards
Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
Luke Kenneth Casson Leighton
2017-07-12 13:12:33 UTC
Permalink
Raw Message
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Pablo Rath
...
Post by Luke Kenneth Casson Leighton
the first step *really is* to quite literally copy - verbatim - the
gnu devel.html page and "generify" it.
where it says "we recommend savannah" put instead "we recommend the
use of a Libre Hosting Service which has a minimum criteria of an A,
as defined by the FSF's Hosting Criteria".
where it says "we recommend mailing lists on gnu.org" put instead "we
recommend the use of software libre hosted mailing lists". a later
revision should go into further detail as to *why* "announce",
"users", "dev" etc. is recommended.
etc. etc.
As it seems to me the above points are done. Thank you Luke for
fixing my mishappened sentence.
There is now a point for version control, mailing lists and web pages at
the wiki (http://rhombus-tech.net/proposed_best_practices/).
Regarding the goal of a general standard for libre projects I don't
think it is necessary to cover the quite specific further points of the
gnu devel.html page: "FTP", "Login accounts", "Hydra: Continuous builds and portability
testing" and "platform-testers: Manual portability testing".
if mentioned at all there should be some documented "upload /
download" method (upload for developers, download for users) but
nothing quite as specific as "You Must Use FTP" or even saying how to
set up FTP. "use libre hosting service" pretty much covers what needs
to be done here.

build-testing? other than "if it is needed, using libre source build
and test programs so that people can duplicate the test and build
results for themselves" is *partially* covered under the terms of the
GNU GPL(s).... but *not* if people say use the Apache License.

so... yes, my feeling is that build and test procedures *if used
and/or needed* should really be specified in a general way.
Post by Pablo Rath
Has anyone else started to work on it (offline)?
been too busy here
Post by Pablo Rath
How long shall the first draft of the standard be (e.g. 10 pages, 100 pages, as long as
necessary)?
short... but as long as necessary. i don't see any reason it should
be longer than 10 pages.
Post by Pablo Rath
As you can see I am looking for guidance and some kind of roadmap to
prevent working in the wrong direction.
great!

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send
Jean Flamelle
2017-07-13 13:11:08 UTC
Permalink
Raw Message
Meh, I don't really think myself ready to write this kind of a document.
I really don't know as much as I'd like to on the topic.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.c
Luke Kenneth Casson Leighton
2017-07-13 14:19:49 UTC
Permalink
Raw Message
Post by Jean Flamelle
Meh, I don't really think myself ready to write this kind of a document.
I really don't know as much as I'd like to on the topic.
well... would you like to help evaluate some of the long-standing
well-known free software projects out there? i vaguely recall making
a list a few weeks ago. we need a table showing what "features" each
of them has. do they use mailing lists, do they have a forum, do they
have a charter, do they have a "code of conduct" *shudder*, do they
properly honour free software licenses or do they have some sort of
unethical "forced contributor agreement" (oracle in particular).

a comparison of pre and post forks for major projects such as x11 /
xorg, openoffice / libreoffice, mysql / mariadb, and so on, would be
really *really* interesting and informative.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.
Jean Flamelle
2017-07-14 13:18:10 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
Post by Jean Flamelle
Meh, I don't really think myself ready to write this kind of a document.
I really don't know as much as I'd like to on the topic.
well... would you like to help evaluate some of the long-standing
well-known free software projects out there? i vaguely recall making
a list a few weeks ago. we need a table showing what "features" each
of them has. do they use mailing lists, do they have a forum, do they
have a charter, do they have a "code of conduct" *shudder*, do they
properly honour free software licenses or do they have some sort of
unethical "forced contributor agreement" (oracle in particular).
a comparison of pre and post forks for major projects such as x11 /
xorg, openoffice / libreoffice, mysql / mariadb, and so on, would be
really *really* interesting and informative.
l.
I would be glad to do that!
I think it would be very important to focus on projects that create
software or firmware, which are of particular relevance to
non-programmers. I think this because they'll likely be under
significantly disproportionate proportionate pressure compared to the
amount of contributions to code that they receive. Blender, Gimp, and
Aperture, are just a few that come to mind immediately, but projects
like RISC-V and Kicad would arguably also count since there are still
large portions of their audiences likely specialize very far away from
the type of software programming knowledge required to contribute.

I think for most people the inclination to donate to any software
projects fiscally, would be predictable (with a high confidence value)
by the the ratio of technical programming knowledge and their
dependence on the software created by that project. For that reason
you could also say, it would be a higher priority to evaluate gnome as
as a software project than debian, because ubuntu is more often
pitched to a less technical audience. Of course, the fsf already
evaluates distributions and doesn't endorse ubuntu anyway, so it would
probably be perceived in really bad taste if the libre community
started listing reasons why they gave gnome a poor evaluation score if
that was the outcome, so I suppose it would be best to avoid it all
together and only evaluate desktop environments as software projects
if the are made available in an fsf-endorsed distribution by default.
(I know I've heard people say trisquel is based on ubuntu, but I don't
know what desktop environment it uses by default).

All in all, for a base, I think aperture would be a good starting
point, since GIMP and Blender get a lot of flack that aperture doesn't
atm. I realize most of what they are doing is hardware, but their is a
lot of firmware involved. Also, I haven't heard very many complaints
about inkscape, so that would be a decent one to start with. I'm
hesitant to talk about OpenShot or libreoffice early on, because they
are (as we like to say in the wikipedia community) POV-forks than
independent projects. In other words, it's impossible to honestly and
sincerely evaluate LibreOffice as a project without comparing it to
OpenOffice and likewise OpenShot to Blender and in small part
Audacity.

Since I don't feel especially confident in my ability handling this
topic, I would probably sooner get feedback through this thread than
add any "evaluations" I make straight to the wiki. Because of this, I
think it's important I start by documenting on which ever of the "good
candidate" projects attracts the most interest in this thread, at
least on the philosophical level of how they "go about their business"
if not on a fundamental level of "I really like this project".

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Luke Kenneth Casson Leighton
2017-07-14 15:36:49 UTC
Permalink
Raw Message
Post by Jean Flamelle
Post by Luke Kenneth Casson Leighton
well... would you like to help evaluate some of the long-standing
well-known free software projects out there? i vaguely recall making
I would be glad to do that!
yay!
Post by Jean Flamelle
I think it would be very important to focus on projects that create
software or firmware, which are of particular relevance to
non-programmers. I think this because they'll likely be under
significantly disproportionate proportionate pressure compared to the
amount of contributions to code that they receive. Blender, Gimp, and
Aperture, are just a few that come to mind immediately, but projects
like RISC-V and Kicad would arguably also count since there are still
large portions of their audiences likely specialize very far away from
the type of software programming knowledge required to contribute.
oo good point. yeah feel free to add some to the list.

doing the samba one, it really didn't take long. took about... 4
minutes? looked to see if they have a charter (they don't), looked at
their "dev" page to see if they have a VCS (they do: git), etc. etc.
oh - i forgot one column: IRC channels!

http://rhombus-tech.net/proposed_best_practices/

added.
Post by Jean Flamelle
I think for most people the inclination to donate to any software
projects fiscally, would be predictable (with a high confidence value)
by the the ratio of technical programming knowledge and their
dependence on the software created by that project. For that reason
you could also say, it would be a higher priority to evaluate gnome as
as a software project than debian, because ubuntu is more often
pitched to a less technical audience.
ok the first phase is: get the info. evaluation comes later.
Post by Jean Flamelle
Of course, the fsf already
evaluates distributions
not like this they don't. they evaluate them for *freedom* related
(ethical) criteria. the purpose of this exercise is to first compile
a list of projects and then "distil" the best and most efffective
*development* practices, by demonstrating provably that, of the top
NN% most highly respected projects, this is what they do.

that's very very different... and means that the FSF's development
practices (ok actually the GNU projects') are "on the list for
evaluation".
Post by Jean Flamelle
and doesn't endorse ubuntu anyway, so it would
probably be perceived in really bad taste if the libre community
started listing reasons why they gave gnome a poor evaluation score if
that was the outcome, so I suppose it would be best to avoid it all
together and only evaluate desktop environments as software projects
if the are made available in an fsf-endorsed distribution by default.
(I know I've heard people say trisquel is based on ubuntu, but I don't
know what desktop environment it uses by default).
All in all, for a base, I think aperture would be a good starting
point, since GIMP and Blender get a lot of flack that aperture doesn't
atm.
well.... we would get to find that out as part of having a look at
exactly what each of those projects do, and then seeing if there's a
correlation, yes?

but first we need to collect the information.

oh. also, we need to make some sort of measure of the
"effectiveness" of the project. whether it's caused people hassle
(taken up inordinate amounts of time), whether the developers are
liked or despised, whether they are welcoming and supportive of
contributors (or not), how many people use it, and so on.

it'll actually be quite a fascinating study.
Post by Jean Flamelle
I realize most of what they are doing is hardware, but their is a
lot of firmware involved. Also, I haven't heard very many complaints
about inkscape, so that would be a decent one to start with. I'm
hesitant to talk about OpenShot or libreoffice early on, because they
are (as we like to say in the wikipedia community) POV-forks than
independent projects. In other words, it's impossible to honestly and
sincerely evaluate LibreOffice as a project without comparing it to
OpenOffice and likewise OpenShot to Blender and in small part
Audacity.
that's *exactly* the point of the exercise.... but that should not be
done *right now*. at the moment all i would like there to be is a
collation of "info". 3-4 minutes per project, "do they have a charter
yes no do they use version control yes no is their infrastructure
libre-hosted yes no".

that's all.
Post by Jean Flamelle
Since I don't feel especially confident in my ability handling this
topic, I would probably sooner get feedback through this thread than
add any "evaluations" I make straight to the wiki.
right now all that needs to be done is find the website for the
project, and record what you find. take a look at the samba one as a
starting point.
Post by Jean Flamelle
Because of this, I
think it's important I start by documenting on which ever of the "good
candidate" projects attracts the most interest in this thread, at
least on the philosophical level of how they "go about their business"
if not on a fundamental level of "I really like this project".
we can discuss that later. and make sure that ideas on how to
evaluate / compare projects are recorded in the wiki. but... later.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.p
Jean Flamelle
2017-07-14 16:02:59 UTC
Permalink
Raw Message
rhombus-tech.net appears to be down for me atm lol

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attach
Luke Kenneth Casson Leighton
2017-07-14 17:51:54 UTC
Permalink
Raw Message
Post by Jean Flamelle
rhombus-tech.net appears to be down for me atm lol
http://downforeveryoneorjustme.com/rhombus-tech.net

it's just you :)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
Jean Flamelle
2017-07-15 17:04:39 UTC
Permalink
Raw Message
That was weird, but anyways I updated the table by reorganizing it,
cleaned the source a bit, added data for apertus and projects on the
list.

Let me know what you think of the formating changes.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@file
Jean Flamelle
2017-07-15 17:05:21 UTC
Permalink
Raw Message
put some more projects on the list*

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne
Luke Kenneth Casson Leighton
2017-07-15 18:07:09 UTC
Permalink
Raw Message
Post by Jean Flamelle
That was weird, but anyways I updated the table by reorganizing it,
cleaned the source a bit, added data for apertus and projects on the
list.
*well-known* :) is urbit actually... well-known??
Post by Jean Flamelle
Let me know what you think of the formating changes.
liked some, didn't like others. "etiquette guidelines" doesn't have
the same toxic punch as "code of conduct" is well-known for. liked
the idea of including the VCS and if it's libre-hosted (likewise for
bugtracker) but *not* the wording you chose ("self-hosted").
self-hosted could mean "proprietary and therefore unethical" and
people would put "yeah it's GR8 maaan!" so i changed it back
*specifically* to "is it libre hosted yes or no" because that's really
important.

basically we're collating info - evidence - that ethical (or
unethical) practices support a project's lifecycle... and other
obseervations. what practices make a project both ethical *and*
long-term successful.

also i turned the table round by 90 degrees as i could see it getting
far too long, and then broke them down into related groups. still
some TODO.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to a
zap
2017-07-15 19:57:07 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
liked some, didn't like others. "etiquette guidelines" doesn't have
the same toxic punch as "code of conduct" is well-known for. liked
the idea of including the VCS and if it's libre-hosted (likewise for
bugtracker) but *not* the wording you chose ("self-hosted").
self-hosted could mean "proprietary and therefore unethical" and
people would put "yeah it's GR8 maaan!" so i changed it back
*specifically* to "is it libre hosted yes or no" because that's really
important.
basically we're collating info - evidence - that ethical (or
unethical) practices support a project's lifecycle... and other
obseervations. what practices make a project both ethical *and*
long-term successful.
also i turned the table round by 90 degrees as i could see it getting
far too long, and then broke them down into related groups. still
some TODO.b
l.
I think any distro that is at devuan standards or better should be on
the list.

I would have said debian standard, but, I thought you might want me to
stay clear of that... so yeah...

as for repositories for hosting libre packages, notabug and gogs are
good ones.


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Se
Luke Kenneth Casson Leighton
2017-07-16 06:27:45 UTC
Permalink
Raw Message
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by zap
I think any distro that is at devuan standards or better should be on
the list.
agreed.
Post by zap
I would have said debian standard, but, I thought you might want me to
stay clear of that... so yeah...
... hadn't occurred to me at all, but now that you mention it, let's
think about it... yes i would, because each project stands on its own
merits and is responsible for its own management.
Post by zap
as for repositories for hosting libre packages, notabug and gogs are
good ones.
are they well-known, well-established and prominent?

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large a
zap
2017-07-16 16:26:40 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
Post by zap
as for repositories for hosting libre packages, notabug and gogs are
good ones.
are they well-known, well-established and prominent?
l.
Notabug is used for libreboot so it cannot be a bad idea. as for gogs,
librecmc uses gogs.
Post by Luke Kenneth Casson Leighton
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Christian Pietsch
2017-07-17 10:40:34 UTC
Permalink
Raw Message
Hi EOMA68 community,

the Free Software Foundation Europe chose Gitea, a gogs fork, for their new source code hosting service: https://git.fsfe.org/

Cheers,
Christian
Post by zap
Post by Luke Kenneth Casson Leighton
Post by zap
as for repositories for hosting libre packages, notabug and gogs are
good ones.
are they well-known, well-established and prominent?
l.
Notabug is used for libreboot so it cannot be a bad idea. as for gogs,
librecmc uses gogs.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo

Jean Flamelle
2017-07-16 05:58:56 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
liked some, didn't like others. "etiquette guidelines" doesn't have
the same toxic punch as "code of conduct" is well-known for.
The word "code" in "code of conduct" does usually implies formal
membership, so I thought it might be confusing to some people if the
phrase became popular in closed circles.

Etiquette guidelines isn't perfect either, because samba technically
actually has a page called "Etiquette" however that refers to trimming
mailing list posts and not in any way how people ought to treat each
other.

Perhaps "Contributor Conduct Guidelines"?

liked
Post by Luke Kenneth Casson Leighton
the idea of including the VCS and if it's libre-hosted (likewise for
bugtracker) but *not* the wording you chose ("self-hosted").
I opted to separate it like that to make it more unambiguous, since
there are two possible definitions of libre in regard to websites:
open-source/free scripts and open-source/free server code. Most
browsers provide no practical way to prove the source code belongs to
the scripts actually sent by the server, without running them, and
because of this it might be argued that the server code should also be
libre so that anyone could run an offline mirror.

If we say arbitrarily that a website is libre it could mean one of
three things: functions w/o script, open-source/free scripts, or
open-source/free server code.

The assumption is that if the server code is libre, then self-hosting
should make by extension the repositories libre. Though, I suppose
there would be nothing hindering someone from just omitting that part
of the server code, on second thought. It's a tricky situation.
Post by Luke Kenneth Casson Leighton
also i turned the table round by 90 degrees as i could see it getting
far too long, and then broke them down into related groups. still
some TODO.
Thanks, much less cluttered!

I use cut-and-paste to convert the spaces to tabs just now to clean the source.

Also, on a side note, I put urbit on there because they are unorthodox
and because they have an unusually high ratio interest compared to
people actually able to contribute, much like you would expect from
RISC or KiCAD, but not 'another' replacement for apache.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-n
Luke Kenneth Casson Leighton
2017-07-16 06:41:20 UTC
Permalink
Raw Message
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Jean Flamelle
Post by Luke Kenneth Casson Leighton
liked some, didn't like others. "etiquette guidelines" doesn't have
the same toxic punch as "code of conduct" is well-known for.
The word "code" in "code of conduct" does usually implies formal
membership, so I thought it might be confusing to some people if the
phrase became popular in closed circles.
no - it's well-known that "code of conduct" is a dangerous, toxic and
highly unethical system of "control" over contributors. *i* didn't know
that, so i did a comprehensive analysis here on the list about 6-8
months ago, and emphatically agreed with the assessment.

unfortunately there are many many projects that have absolutely no
idea of the dangers of "codes of conduct" so continue to deploy them.

so the idea is to *specifically* identify those projects that have one
of these dangerous "codes of conduct" in order to see if there is a
correlation between harm done to developers and end-users and the
use of such toxic documents.
Post by Jean Flamelle
Etiquette guidelines isn't perfect either, because samba technically
actually has a page called "Etiquette" however that refers to trimming
mailing list posts and not in any way how people ought to treat each
other.
okaaay.... sooo.... that should probably go on a "/" mailing list /
ML-etiquette
Post by Jean Flamelle
Perhaps "Contributor Conduct Guidelines"?
no. sorry. explained above.
Post by Jean Flamelle
liked
Post by Luke Kenneth Casson Leighton
the idea of including the VCS and if it's libre-hosted (likewise for
bugtracker) but *not* the wording you chose ("self-hosted").
I opted to separate it like that to make it more unambiguous, since
open-source/free scripts and open-source/free server code.
hmmm.... *thinks*... is the distinction important? don't know. so
it should probably go on the list. it might be statistically
significant.

so a column "Web site source available / License"
and now that i think about it "Documentation source available / License"

should be added
Post by Jean Flamelle
Most
browsers provide no practical way to prove the source code belongs to
the scripts actually sent by the server, without running them,
someone somewhere will run librejs to determine that
Post by Jean Flamelle
and
because of this it might be argued that the server code should also be
libre so that anyone could run an offline mirror.
more importantly they can *fork* the project.... but only if the full
source of the web site server source is available and does not
critically depend on proprietary components.
Post by Jean Flamelle
If we say arbitrarily that a website is libre it could mean one of
three things: functions w/o script, open-source/free scripts, or
open-source/free server code.
true.
Post by Jean Flamelle
The assumption is that if the server code is libre, then self-hosting
should make by extension the repositories libre. Though, I suppose
there would be nothing hindering someone from just omitting that part
of the server code, on second thought. It's a tricky situation.
Post by Luke Kenneth Casson Leighton
also i turned the table round by 90 degrees as i could see it getting
far too long, and then broke them down into related groups. still
some TODO.
Thanks, much less cluttered!
I use cut-and-paste to convert the spaces to tabs just now to clean the source.
yuck. please don't: i use 4-spaces-per-tab where other people will
use 8. also, the reason for using spaces is because you can just put
your editor into "replace" mode and the formatting remains stable.

please put it back.
Post by Jean Flamelle
Also, on a side note, I put urbit on there because they are unorthodox
and because they have an unusually high ratio interest compared to
people actually able to contribute, much like you would expect from
RISC or KiCAD, but not 'another' replacement for apache.
hmmm, ok, cool. hmm... reminds me, established date should be added.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac
Jean Flamelle
2017-07-16 11:26:02 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
Post by Jean Flamelle
The word "code" in "code of conduct" does usually implies formal
membership, so I thought it might be confusing to some people if the
phrase became popular in closed circles.
no - it's well-known that "code of conduct" is a dangerous, toxic and
highly unethical system of "control" over contributors. *i* didn't know
that, so i did a comprehensive analysis here on the list about 6-8
months ago, and emphatically agreed with the assessment.
Ah - I see. I think I see it as more a representation of what
moderators will probably do regardless of if said document exists or
not. I think it very toxic if they try to hurt project forks that do
things differently, but moderators inevitably will try to establish a
certain culture within their project and documenting the moderators
behaviors will set the right expectations in people.

Inevitably, and especially as the open-source and free software
communities grow, there will be project forks based simply on certain
people that can't cooperate with each other. I think this kind of
conflict can breed a healthy diversity in people, so, if a small group
of contributors write up a small "code of conduct" on how they like to
be treated, I think that can be healthy depending on the
circumstances.

I see it that such a doc could mean "don't talk to me, if you do X" or
it could mean "you can't have my code, if you do X". The former is all
well and fine, but the later I'd agree is toxic.
Post by Luke Kenneth Casson Leighton
Post by Jean Flamelle
I opted to separate it like that to make it more unambiguous, since
open-source/free scripts and open-source/free server code.
hmmm.... *thinks*... is the distinction important? don't know. so
it should probably go on the list. it might be statistically
significant.
so a column "Web site source available / License"
and now that i think about it "Documentation source available / License"
should be added
I'm starting to really feel the usefulness of collecting this data :>
Post by Luke Kenneth Casson Leighton
yuck. please don't: i use 4-spaces-per-tab where other people will
use 8. also, the reason for using spaces is because you can just put
your editor into "replace" mode and the formatting remains stable.
please put it back.
I got this error trying to revert the change back "Error: Failed to
revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert
--no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: "

Hm, the web editor uses a proportional-pitch font, so it's impossible
to tell the number of spaces in a table to get alignment. (didn't
realize you could use git to edit it, so I thought you also saw this.)

I'm not in on the spaces v. tabs holy war. lol

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.
Luke Kenneth Casson Leighton
2017-07-16 13:12:29 UTC
Permalink
Raw Message
Post by Jean Flamelle
I got this error trying to revert the change back "Error: Failed to
revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert
--no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: "
yep you'll need to do it manually: i edited the page in the meantime. sorry.
Post by Jean Flamelle
Hm, the web editor uses a proportional-pitch font, so it's impossible
to tell the number of spaces in a table to get alignment.
stuff it into a text editor with a fixed-width font.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm
Luke Kenneth Casson Leighton
2017-07-16 13:14:26 UTC
Permalink
Raw Message
On Sun, Jul 16, 2017 at 2:12 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
Post by Jean Flamelle
I got this error trying to revert the change back "Error: Failed to
revert commit 27584a06584f4942b6d24bda08511cedd3f867d3 'git revert
--no-commit 27584a06584f4942b6d24bda08511cedd3f867d3' failed: "
yep you'll need to do it manually: i edited the page in the meantime. sorry.
Post by Jean Flamelle
Hm, the web editor uses a proportional-pitch font, so it's impossible
to tell the number of spaces in a table to get alignment.
stuff it into a text editor with a fixed-width font.
... or... get the previous version, work out what i did, go the
previous-previous version, restore that (manually) then hand-add what
i added...

ah y'know what? sod it - i have access to git: i'll do it :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Luke Kenneth Casson Leighton
2017-07-16 13:19:07 UTC
Permalink
Raw Message
On Sun, Jul 16, 2017 at 2:14 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
Post by Jean Flamelle
Hm, the web editor uses a proportional-pitch font, so it's impossible
to tell the number of spaces in a table to get alignment.
stuff it into a text editor with a fixed-width font.
... or... get the previous version, work out what i did, go the
previous-previous version, restore that (manually) then hand-add what
i added...
ah y'know what? sod it - i have access to git: i'll do it :)
done. there's no "war" on tabs/spaces, there's just "one is more
appropriate for the circumstances than the other". for c i always
use tabs. for python i *always* follow PEP8. it always depends on
circumstances.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to a
Pablo Rath
2017-07-17 10:26:04 UTC
Permalink
Raw Message
Post by Luke Kenneth Casson Leighton
oh - i forgot one column: IRC channels!
http://rhombus-tech.net/proposed_best_practices/
added.
Should we also add a line and check if the projects have a wiki.
Personally I get a ton of information from Debian and Arch wikis and
they a good way for collaboration between developers and users.

kind regards
Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
Luke Kenneth Casson Leighton
2017-07-17 10:27:27 UTC
Permalink
Raw Message
Post by Pablo Rath
Post by Luke Kenneth Casson Leighton
oh - i forgot one column: IRC channels!
http://rhombus-tech.net/proposed_best_practices/
added.
Should we also add a line and check if the projects have a wiki.
Personally I get a ton of information from Debian and Arch wikis and
they a good way for collaboration between developers and users.
good point - "wiki / license"

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac
Hendrik Boom
2017-06-06 13:47:29 UTC
Permalink
Raw Message
Post by John Luke Gibson
Alrightie~!
Foremost, since "existing" free software and cultural works aren't
likely to be sold, I think a libre software standards organization
wouldn't certify individual works or pieces of code, so much as
projects as a whole including roles performed by non-developers
Version control is almost ubiquitously used for source code, to the
point it should hardly need mentioned; however very rarely are
non-source project files, such as .blend files, collaboratively
designed this way. I don't think people are unwilling to use version
control in this way, rather they just don't think of it since most
artists aren't developers and art has been digitally designed for much
longer than version control systems have been easy to use. So I think
uploading files to repository and saving changes as commits, would be
a good 'non-developer' "best practice" to apply to a software
certification standard.
A lot of file formats, especially those used by artists, are hostile
to the essential 'merge' operation in version control.

Even the current real standards for word processors (such as odt) are
bad for this.

They use compression, which has an effect like cryptographic hashing
on ones efforts to distinguish change from background.

Even the uncompressed .odf word processor format has this problem,
being based on xml. If a merge operation sees enough similarity it
guesses what the actual changes are. If it guesses wrong the merged
file may have its bracket structure severely damaged, requirg manual
repair. But users do not interact with their documents at the XML
level, so they are completely lost.

Why this isn't a problem with C is that programmers do interact with
their code in a textual level, so they ar very familiar with the
editing of brackets.

For word processing, I think the only good solution is a document
compiler, with the writer editing the source code.

I know of nothing comparable for visual arts.

-- hendrik

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Sen
Luke Kenneth Casson Leighton
2017-06-06 14:00:59 UTC
Permalink
Raw Message
Post by Hendrik Boom
For word processing, I think the only good solution is a document
compiler, with the writer editing the source code.
I know of nothing comparable for visual arts.
there are two separate concepts here: revision control of
non-text-based documents, and the relevance of "art" to science.

the first is a well-known problem, for which things like "yodl",
"tex" and other
complex-document-formats-from-easy-text-based-generators already
exist.

another example: i wrote pyopenscadobj and am the de-facto maintainer
of pyopenscad, because you can write python programs which generate
SCAD files which in turn generates 3D models.... and the python
programs can be checked into git revision control. can you check in
.blend or .iges or .step files into git revision control? no you
can't because they're a dog's dinner.

for file formats which do *not* lend themselves to this technique,
all i really have to say on the subject is: tough titty. find an
alternative program and file-format... or just put up with the fact
that your git repository becomes nothing more than a file store with
zero ability to store or track "differences".


the second, hendrik, you may have misunderstood why "art" was
mentioned in the context of science and engineering. we are *not*
discussing "traditional artistic subjects" such as painting, sculpting
and so on.

we are referring to (as does the hippocratic oath) the application of
artistic *principles* to scientific endeavour, which is something that
is, admittedly, quite hard to understand let alone actually do.

some examples include: taking "intuitive" decisions in solving
engineering problems; applying "creativity"; and other such things.
these are *general principles* which are most commonly used in the
"arts", and hippocrates was pointing out that when science does *not*
apply them then science suffers.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.
John Luke Gibson
2017-06-06 15:36:24 UTC
Permalink
Raw Message
Post by Hendrik Boom
A lot of file formats, especially those used by artists, are hostile
to the essential 'merge' operation in version control.
A lapse on my part. I didn't think of that when I was typing that
whole thing up.
That makes it quite a bit difficult, as multiple forks can't be merged
and one simply has to decide between them, then, if worthwhile,
refactor the new version to include the merits of other forks. Okay,
maybe not possible for 100+ collaborators xD

On the bright side, it appears to be a problem that's been tackled
before for blender:
https://blenderartists.org/forum/showthread.php?344037-Addon-Blender-Git-Versioning

It would be interesting if there might be a way to convert blend files
to python, since blender has heavy support of its python api.

This problem appears to have been solved for gimp, under the radar:
https://sites.google.com/site/httimchen/2011_imagesvn
Post by Hendrik Boom
the second, hendrik, you may have misunderstood why "art" was
mentioned in the context of science and engineering. we are *not*
discussing "traditional artistic subjects" such as painting, sculpting
and so on.
we are referring to (as does the hippocratic oath) the application of
artistic *principles* to scientific endeavour, which is something that
is, admittedly, quite hard to understand let alone actually do.
Naw, one of my tings definitely did mention CVS of art assets
somewhere in dat confuddled mess xd

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.
Luke Kenneth Casson Leighton
2017-06-06 16:43:46 UTC
Permalink
Raw Message
Post by John Luke Gibson
Post by Luke Kenneth Casson Leighton
we are referring to (as does the hippocratic oath) the application of
artistic *principles* to scientific endeavour, which is something that
is, admittedly, quite hard to understand let alone actually do.
Naw, one of my tings definitely did mention CVS of art assets
somewhere in dat confuddled mess xd
that is still completely out-of-scope for the discussion. we are not
here to solve the problem of version control for artists or sculptors.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
m***@gmail.com
2017-06-12 06:42:29 UTC
Permalink
Raw Message
Post by Hendrik Boom
For word processing, I think the only good solution is a document
compiler, with the writer editing the source code.
The're is a way for arbitrary documents so work with version control.
conversion to an intermediate format like markdown.
http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/
https://github.com/vigente/gerardus/wiki/Integrate-git-diffs-with-word-docx-files

It uses pandoc to convert to markdown and then to git.

Found it on hackady
http://hackaday.com/2017/05/23/stupid-git-tricks
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb
Loading...