done
On 20.07.2014 00:30, erik quanstrom wrote:
The Wiki seems to be frozen (i.e., not editable anymore):
- no Edit button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
- no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
444)
edit from plan 9.
- erik
thanks.
On 20.07.2014 02:12, Brian L. Stuart wrote:
My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in
the current model.
2. submitting trivial contributions is not trivial for the
contributor.
Both of these points seem to come
I would like first to thank everyone for the kind replies!
Each was useful in it's own way.
On 18.07.2014 16:36, erik quanstrom wrote:
Yet: is there a source control system behind it?
Would it be possible to check out directly from there?
there is nothing most folks would recognize as a
You are not the first one to bring this up. There is a chain titled
CMS/MMS (VCS/SCM/DSCM) [was syscall 53] that discusses it. I'd suggest
giving it a skim if you can find it in the archives.
That said, in my opinion:
1. The history is confined to Plan9.
It is hard to do small fixes
Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).
On Sat, Jul 19, 2014 at 11:31 AM, dante subscripti...@posteo.eu wrote:
I would like first to thank everyone for the kind replies!
Each was useful in it's own way.
On 18.07.2014 16:36, erik quanstrom
Hi,
On 19.07.2014 13:20, Riddler wrote:
3. Contrib packages are tied to people; there is no common
repository.
This leads to the situation where you can't update a package
of a long gone user.
Please tell me how many Mercurial packages you can find in
Contrib!
I don't see how a
On 19.07.2014 13:49, pmarin wrote:
Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).
And this might lead to the problems pointed in my previous mails.
Or not, I might be wrong.
Kind Regards,
Dante
This was an unfair statement from you, pmarin.
You make me answer twice.
I did not imply anywhere that I proposed the bazaar model (whatever
that is, no one wants the Linux .
Scalability is also possible in projects maintained by a central
authority.
My whole argument goes about the
On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote:
Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).
The Bazaar model is the one for not doing or undoing.
Small is beautiful. The attraction for Plan9 is its consistency and size.
As far as I'm
Please, be so kind and stop this Bazaar thread.
The proposal was to use some maybe more scalable tools while
maintaining the current responsibilities.
This could allow for more contributions to be done with the same burden
for the maintainers.
An example for what it's worth could be OpenBSD.
1. The history is confined to Plan9.
It is hard to do small fixes (typos, documentation) from another
system.
that's true. but it's easy to get a plan 9 system, or drawterm into one.
in my experience, plan 9 is a system one spends siginficant time in.
i would not want to change the
On Sat, Jul 19, 2014 at 11:31 AM, dante subscripti...@posteo.eu wrote:
It is hard to do small fixes (typos, documentation) from another system.
One could argue this is a feature. Everything has to be tested.
I've seen way too many botched patches that purportedly only fixed
documentation. Also,
Hi Eric,
Thanks for your answers! They are really a good start for me with
Plan9.
So, you and the others convinced me that a source management system for
the main system is not really necessary.
What's left from my initial questions is if it won't be a bad idea to
have an integrated contrib
Are you intentionally trying to make plan bureaucratic?
Usable, not bureaucratic.
And you don't need to invest work.
Just use it if you like it.
Take a look at how it works now. Is this OK with you?
1. /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
Why do I need to know about fgb, why not
1. Gather the good packages from the user's directories and other
sources on the net into a central system, like the core Plan9.
There is some work implied to check licenses and get permissions.
Try 9front :)
yes
On 19.07.2014 19:31, hiro wrote:
1. Gather the good packages from the user's directories and other
sources on the net into a central system, like the core Plan9.
There is some work implied to check licenses and get
permissions.
Try 9front :)
Quoting dante subscripti...@posteo.eu:
Usable, not bureaucratic.
Lots of people already use plan 9, therefore it is already
useable.
And you don't need to invest work.
This seems like a load of garbage, since you're already demanding
that other people do work to support your preferences.
1. /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
Why do I need to know about fgb, why not
/n/sources/packages/contrib/rc/bin/contrib/install contrib ?
2. bichued/hg -- 1.0.2
jas/hg-src
mjl/hgfs
stallion/mercurial -- 2.2.3
Which one now?
this is
On Jul 19, 2014, at 8:02 , dante subscripti...@posteo.eu wrote:
My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in the current model.
Okay, it *may* not. But we have no evidence of that. There's no indication that
the current
On Jul 19, 2014 1:17 PM, erik quanstrom quans...@quanstro.net wrote:
[snip]
- having an SSH2 server (there is one in 9atom, but I didn't see
it in the stock Plan9). Are you sure it doesn't have the Heartbleed?
i'm sure it doesn't have heartbleed. code for that sort of renegotiation
On Sat, Jul 19, 2014 at 9:20 PM, Christopher Nielsen cniel...@pobox.com wrote:
Not to mention heartbleed has nothing to do with ssh... It was an
implementation bug in openssl only; it wasn't even a protocol bug.
Yes, OpenSSH doesn't even use OpenSSL.
--
Aram Hăvărneanu
On 19.07.2014 20:17, erik quanstrom wrote:
3. What about
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ?
What about the broken links there?
Can we still save that software?
Archive.org?
you may edit the wiki yourself to correct these issues.
The Wiki seems to
The Wiki seems to be frozen (i.e., not editable anymore):
- no Edit button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
- no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
444)
edit from plan 9.
- erik
you may edit the wiki yourself to correct these issues.
The Wiki seems to be frozen (i.e., not editable anymore):
- no Edit button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
It was changed some time back to allow edits only using
the acme wiki interface, rather
- having an SSH2 server (there is one in 9atom, but I didn't
see it in the stock Plan9).
Geoff included the same ssh implementation as 9atom
has in /sys/src/cmd/ssh2 but with some code clean-up.
So the server code is there. I've been meaning to go
back an reconcile the two different
My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in
the current model.
2. submitting trivial contributions is not trivial for the contributor.
Both of these points seem to come from a mental model
that just doesn't apply to Plan 9.
Sources is not kept up-to-date by volunteers, unless you mean
contrib, it is maintained by the Labs. Also, in a way, the sources
server *is* Plan 9, rather than being updated *with* Plan 9.
Plan 9 doesn't traditionally use version control. Rather, most
disk-based Plan 9 file servers offer some
Yet: is there a source control system behind it?
Would it be possible to check out directly from there?
for the bell-labs distribution, the filesystem itself keeps
a daily record of the source tree. you can access it with
9fs sourcesdump and the daily state of sources will be
in
Yet: is there a source control system behind it?
Would it be possible to check out directly from there?
there is nothing most folks would recognize as a distributed
revision control system.
the repo is sources itself. history is through history(1).
you can check out code with cp(1), tar(1),
30 matches
Mail list logo
