Re: the state of the linuxppc-dev community

Re: the state of the linuxppc-dev community

[Tom Rini]

On Tue, 8 Feb 2000, Dan Bethe wrote:

> 	The problem is that LinuxPPC.org has a development environment that is
> splintered, unstable, undocumented, obscure, nonintuitive, and basically
> impenetrable even to people who are fully dedicated to it such as Gabe and
> myself.  It is run almost exclusively on tribal knowledge that is only in the
> heads of the people who are writing the ppc-specific core of the OS.  There are
> no procedures and no interface.  And there is very little respect toward people
> like me and Gabe who have the time, dedication, and skills to clean it all up.

Well, yes.  A lot of it comes from everything else being splintered.
Userland is atleast somewhat unified.  Everybody (well, almost) uses at
least a common compiler/glibc.  Thats where the reference release came
in/out of.  We needed to hit glibc 2.1 and we needed everybody else to as
well.  Check out http://www.crashing.org/pressrel.txt (No, the 1.1 update
wasn't as widely published as 1.0, but it still hit lwn).  The kernel is a
whole 'nother ball of wax.

> 	First, obviously, we have to map out how everything currently is, before we
> could even suggest anything better.  But because 90% of the responses we get
> are either dead silence or asinine arguments like yours, we are slowly getting
> nowhere.  The remaining 10% are the responses of a mob cheering us on just for
> having pointed out the silly state of the maintenance of LinuxPPC.

By and large, there aren't many problems, directly related to userland.
compiler and libc bugs get pointed out on the proper lists (ie
gcc-*@gcc.gnu.org, or wherever the glibc bug program points you).  The
problem lies in that the two listed MAINTAINERS for Linux/PPC are either
busy and quite or just quite.  2.3.x still doesn't run on most machines
iirc, and 2.4 is close.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: the state of the linuxppc-dev community

[Michael Schmitz]

> > So what exactly is the problem? The 2.2.12 source? The .config? The fact
> > that LinuxPPC developers appear to break the GPL by not dropping a fresh
> > source tarball along each kernel binary?
>
> 	I happen to know the problem shared by Gabe, me, and anyone else primarily
> concerned with the stability, robustness, and ease of use of the whole LinuxPPC
> distribution and community authority.
> 	The problem is that LinuxPPC.org has a development environment that is
> splintered, unstable, undocumented, obscure, nonintuitive, and basically
> impenetrable even to people who are fully dedicated to it such as Gabe and
> myself.  It is run almost exclusively on tribal knowledge that is only in the
> heads of the people who are writing the ppc-specific core of the OS.  There are
> no procedures and no interface.  And there is very little respect toward people
> like me and Gabe who have the time, dedication, and skills to clean it all up.

With all due respect: if that's what you wanted to direct our attention
to, you should have said so up front. I'm a bit over sensitzited to people
that wave the GPL argument in my face (being a Debian developer for m68k,
and seeing all the tribal infighting there). That's why I jumped all over
Gabe (your name sounds familiar from c.o.l.powerpc or this list, his
wasn't. Sorry for assuming this was just some moron posting flame bait.)

On the issue at hand: when I started working on PPC last year, I also
noticed that information about patches, kernels, people to talk and send
patches to was hard to find (I remember posting a complaint to that effect
to the NG). Having had some contact with Paul on m68k/PPC code sharing
issues before, I knew where to start asking at least, and sent a few
patches to Paul and BenH. Listening on this list for a while since gave me
a better overview on who's doing what, at least where kernel devlopment is
concerned.

I do see the problem that information is splintered over too many web
pages and FTP servers (I fail to see what this has to do with the GPL). I
would welcome having a central dsitribution independent site gather what's
out on the net, I'm too lazy to dig around for bits of information most of
the time myself. I fail to see how lack of response to your suggestions
(that I see voiced by you and Gabe for the first time now on this list)
constitutes lack of respect for you. I imagine keeping up with the project
at hand may leave little time for developers to think about procedures.
That doesn't mean nobody cares. It's not a high priority for some.

> 	First, obviously, we have to map out how everything currently is, before we
> could even suggest anything better.  But because 90% of the responses we get
> are either dead silence or asinine arguments like yours, we are slowly getting
> nowhere.  The remaining 10% are the responses of a mob cheering us on just for
> having pointed out the silly state of the maintenance of LinuxPPC.

The asinine argument was in reply to a post I perceived as asinine. I hope
you accept that as explanation, and let us move on. The resources I know
of are the FAQ-o-matic, mailing list and archive, c.o.l.powerpc (and
maybe deja archive), ftp.dev.linuxppc.org for all sorts of kernel and user
space updates, rsync servers for stable and development trees, and the
linuxppc.org web site that links to few of the above in no particularly
logical fashion.

I could imagine a reworked web site, plus CVS or other access to the
sources would be a good start. I agree with Tony Mantler on the importance
of CVS - having run the m68k Mac port almost as one-man-show for a year,
switching to CVS encouraged at least five more people to start working on
various parts. Getting the latest sources without waiting for me
to build a new diff, checking in patches directly and improved
communication were instrumental in advancing development.

> 	We have definately produced deeds rather than just words.  Gabe is a primary
> maintainer of Stampede Linux (www.stampede.org), and is working on porting
> Stampede to PPC; and I've accepted jhaas's request to be the primary maintainer
> of LinuxPPC security and of LinuxPPC Powerbook support.  We both use LinuxPPC
> on Powerbook for 99% of our daily work.

More power to you. I hope you can get some of your suggestions on
improving the communication and infrastructure and organizing the
PPC port adopted here. Please keep in mind that not all of us are
'professionals' though. I use LinuxPPC (on a Powerbook) for my daily work,
but I can work on the kernel source only in my spare time, as an amateur.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Martin Costabel]

Michael Schmitz wrote:
[]
> I could imagine a reworked web site, plus CVS or other access to the
> sources would be a good start. I agree with Tony Mantler on the importance
> of CVS - having run the m68k Mac port almost as one-man-show for a year,
> switching to CVS encouraged at least five more people to start working on
> various parts. Getting the latest sources without waiting for me
> to build a new diff, checking in patches directly and improved
> communication were instrumental in advancing development.

Speaking of CVS, I find it strange that nobody in this thread mentions
the vger CVS tree any more (but then I am finding many things strange
recently, "ppclinux".apple.com forgetting mklinux and so on, it's
probably me getting old). Until very recently, this tree maintained a
very up-to-date version of PPC patches. It seems that since yesterday,
PPC support on this tree is officially dead. There are comments like

RCS file: /cvs/linux/linux/include/asm-ppc/hw_irq.h,v
[]
revision 1.3
date: 2000/02/07 21:37:25;  author: davem;  state: Exp;  lines: +1 -1
Not maintained here anymore.

Very sad. As a user, I found CVS much better than rsync, because it
gives much more information and has more intelligence in merging with
local changes. I only hope that bitkeeper will give similar
possibilities.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Geert Uytterhoeven]

On Wed, 9 Feb 2000, Martin Costabel wrote:
> Michael Schmitz wrote:
> []
> > I could imagine a reworked web site, plus CVS or other access to the
> > sources would be a good start. I agree with Tony Mantler on the importance
> > of CVS - having run the m68k Mac port almost as one-man-show for a year,
> > switching to CVS encouraged at least five more people to start working on
> > various parts. Getting the latest sources without waiting for me
> > to build a new diff, checking in patches directly and improved
> > communication were instrumental in advancing development.
>
> Speaking of CVS, I find it strange that nobody in this thread mentions
> the vger CVS tree any more (but then I am finding many things strange
> recently, "ppclinux".apple.com forgetting mklinux and so on, it's
> probably me getting old). Until very recently, this tree maintained a
                                  ^^^^^^^^^^^^^
Say 3-4 months ago.

> very up-to-date version of PPC patches. It seems that since yesterday,
> PPC support on this tree is officially dead. There are comments like
>
> RCS file: /cvs/linux/linux/include/asm-ppc/hw_irq.h,v
> []
> revision 1.3
> date: 2000/02/07 21:37:25;  author: davem;  state: Exp;  lines: +1 -1
> Not maintained here anymore.
>
> Very sad. As a user, I found CVS much better than rsync, because it
> gives much more information and has more intelligence in merging with
> local changes. I only hope that bitkeeper will give similar
> possibilities.

BK should be(come) better than CVS. I'm happy with BK now (sort of, still
getting used to it).

But I understand your frustration: I felt the same during the 2 months between
my vger-cvs and ppc-bk times. Let's hope ppc-bk is opened for the public
soon... IMHO bk is sufficient mature to have a positive netto gain for
Linux/PPC when combining a beta bk with the opening of the PPC kernel tree.

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Martin Costabel]

Geert Uytterhoeven wrote:
>
> On Wed, 9 Feb 2000, Martin Costabel wrote:

> > probably me getting old). Until very recently, this tree maintained a
>                                   ^^^^^^^^^^^^^
> Say 3-4 months ago.

Well, I am running right now a 2.2.15-pre4 from vger, and I have a
working 2.3.42 built from vger with ajoshi's patches applied. Both are
less than 2 weeks old. I admit that here I don't really test the latest
ppc developments (say USB and Pbook), because my main goal right now is
to keep my old Pmac 6400 on board.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Geert Uytterhoeven]

On Wed, 9 Feb 2000, Martin Costabel wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 9 Feb 2000, Martin Costabel wrote:
>
> > > probably me getting old). Until very recently, this tree maintained a
> >                                   ^^^^^^^^^^^^^
> > Say 3-4 months ago.
>
> Well, I am running right now a 2.2.15-pre4 from vger, and I have a
> working 2.3.42 built from vger with ajoshi's patches applied. Both are
> less than 2 weeks old. I admit that here I don't really test the latest
> ppc developments (say USB and Pbook), because my main goal right now is
> to keep my old Pmac 6400 on board.

That's because Cort sends his patches to Linus, and after that they
automagically appear in vger as well. But there was a time Linus' tree didn't
produce a compiling/working PPC kernel at all.

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Michael Schmitz]

> > Speaking of CVS, I find it strange that nobody in this thread mentions
> > the vger CVS tree any more (but then I am finding many things strange
> > recently, "ppclinux".apple.com forgetting mklinux and so on, it's
> > probably me getting old). Until very recently, this tree maintained a
>                                   ^^^^^^^^^^^^^
> Say 3-4 months ago.

At least 2 months from what I recall, but I admit I haven't used vger
since 2.3.18-vger horribly broke booting my Lombard and I couldn't figure
out how to get any console output before framebuffer console init.

> > very up-to-date version of PPC patches. It seems that since yesterday,
> > PPC support on this tree is officially dead. There are comments like
> >
> > RCS file: /cvs/linux/linux/include/asm-ppc/hw_irq.h,v
> > []
> > revision 1.3
> > date: 2000/02/07 21:37:25;  author: davem;  state: Exp;  lines: +1 -1
> > Not maintained here anymore.
> >
> > Very sad. As a user, I found CVS much better than rsync, because it
> > gives much more information and has more intelligence in merging with
> > local changes. I only hope that bitkeeper will give similar
> > possibilities.

Very sad indeed. Though rsync didn't destroy my local changes so far (huge
additions to adb.c, that was easy to merge. Reminds me to send those off
to Paul, argh).

> BK should be(come) better than CVS. I'm happy with BK now (sort of, still
> getting used to it).

And I just got used to CVS :-(( I'd need a BK primer when it gets
available.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Larry McVoy]

: And I just got used to CVS :-(( I'd need a BK primer when it gets
: available.

It's not too bad to get used to.  The main weirdness for most people is that
you are working in a tree with the revision history files right there.  So
if you are in fs/ext2 and you do this

    $ bk clean
    $ ls -F
    SCCS/
    $ bk co
    CHANGES 1.1: 157 lines
    Makefile 1.1: 15 lines
    acl.c 1.1: 17 lines
    balloc.c 1.1: 756 lines
    bitmap.c 1.1: 27 lines
    dir.c 1.2: 212 lines
    file.c 1.4: 173 lines
    fsync.c 1.2: 156 lines
    ialloc.c 1.1: 569 lines
    inode.c 1.4: 932 lines
    ioctl.c 1.1: 90 lines
    namei.c 1.3: 894 lines
    super.c 1.4: 805 lines
    symlink.c 1.1: 43 lines
    truncate.c 1.1: 382 lines
    $ ls -F
    CHANGES   SCCS/  balloc.c  dir.c   fsync.c   inode.c  namei.c  symlink.c
    Makefile  acl.c  bitmap.c  file.c  ialloc.c  ioctl.c  super.c  truncate.c

This makes people a little crazy until they get used to it.  The BitKeeper
model is "one user, one repository" and it's a lot like using straight
RCS or SCCS.  On top of that, we've added the ability to resync and
merge the revision histories.

In some ways, it's based on the observation that basic SCCS/RCS worked fine
as long as it was single user.  We've returned to that model plus added the
ability to have a lot of singler user copies of a project.

Basic stuff you'll need:

    # get yourself a baseline tree
    $ bk clone hq.fsmlabs.com:/home/bk/linuxppc_2_3 linuxppc_2_3

    # Set it up for building/working (this checks out and locks all files)
    $ bk -r edit

    # hack, build, debug, hack, build, debug

    # Run citool to commit (LOCALLY! Not like CVS) your changes
    $ bk citool

    # Update your tree with anything that's happened since last time
    $ bk pull

    # Push back any changes you've made
    $ bk push

    # Browse the tree's changes
    $ bk sccstool

    # Browse a specific file
    $ bk sccstool fs/ext2/super.c

There's tons more but that's all most people ever need.  Cort, did I
forget anything?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P. (Was Re: the state of the linuxppc-dev community)

[Jesper Skov]

>>>>> "Larry" == Larry McVoy <lm@bitmover.com> writes:
Larry> Basic stuff you'll need:

Larry>     # get yourself a baseline tree $ bk clone
Larry> hq.fsmlabs.com:/home/bk/linuxppc_2_3 linuxppc_2_3

Larry>     # Set it up for building/working (this checks out and locks
Larry> all files) $ bk -r edit

Larry>     # hack, build, debug, hack, build, debug

Larry>     # Run citool to commit (LOCALLY! Not like CVS) your changes
Larry> $ bk citool

Larry>     # Update your tree with anything that's happened since last
Larry> time $ bk pull

 bk resolve

 bk -r get

Larry>     # Push back any changes you've made $ bk push

Larry>     # Browse the tree's changes $ bk sccstool

Larry>     # Browse a specific file $ bk sccstool fs/ext2/super.c

Larry> There's tons more but that's all most people ever need.  Cort,
Larry> did I forget anything?


I'm not Cort, but I've been there :)  As I put in above, most people
(that do any hacking) would have to resolve conflicts between their
local tree and changes committed to Cort's tree.

And I find I also have to run 'bk -r get' after a pull to ensure all
new files get "checked out".



As for general usability, with a trained CVS monkey's POV, bk does
take some getting used to. My biggest problem has been finding the
proper documentation(*) - Larry, you may want to post the list above as a
CVS-user's-crash-course on the web site.

Another observation: keeping the repository data in the "build tree"
has caused me to do two things:

 Update my grep scripts and such to ignore SCCS directories.

 Use a buffer tree between Cort's tree and my development tree,
 allowing me to pull new changes without risking conflicts, and
 allowing simple tar-ball backups of the repository (without having to
 filter out checked out source files and random .o files).


Jesper


(*): plenty of documentation in the tools, it's just that I find
     myself clicking around in 'bk helptool' for a long time before I
     find what I need. I would have liked HTML/ASCII documentation
     better.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Vger CVS R.I.P.

[Wolfgang Denk]

In message <otvh3xcs1t.fsf@thinktwice.zoftcorp.dk> you write:
>
> As for general usability, with a trained CVS monkey's POV, bk does
> take some getting used to. My biggest problem has been finding the
> proper documentation(*) - Larry, you may want to post the list above as a
...
> (*): plenty of documentation in the tools, it's just that I find
>      myself clicking around in 'bk helptool' for a long time before I
>      find what I need. I would have liked HTML/ASCII documentation
>      better.

In any case please include ASCII docs  -  I  *hate*  those  so-called
help-tools  with  point-and-click  interfaces  that are *NOT* helpful
because I cannot use grep, and the author had a different idea  about
how I want to search.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.                  - Voltaire

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/