linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Cort Dougan <cort@fsmlabs.com>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: Tom Rini <trini@kernel.crashing.org>,
	linuxppc-embedded@lists.linuxppc.org,
	Murray.Jensen@cmst.csiro.au
Subject: Re: linuxppc_2_5 source tree (and others)
Date: Thu, 10 May 2001 17:11:14 -0600	[thread overview]
Message-ID: <20010510171114.C1595@ftsoj.fsmlabs.com> (raw)
In-Reply-To: <200105102124.f4ALObA452146@saturn.cs.uml.edu>; from acahalan@cs.uml.edu on Thu, May 10, 2001 at 05:24:37PM -0400


Believe me, I know what it looks like.  I'm trying to clean things up but
it's a large problem.  I do appreciate your criticisms though, they are
useful in finding the worst parts.

Just to be clear, though, FSMLabs has nothing to do with Linux/PPC.  I just
happen to work here and use the web/ftp bandwidth.

} I'm sorry I was rude. Please try to imagine what PowerPC Linux
} development must look like to someone who does not happen to
} work for FSM Labs, Montevista, or BitKeeper.

Perhaps I can clear things up a bit.  I wanted _2_4 stable so that it
didn't get brand-new (untested and buggy) code.  I created _2_5 as a
work-area for us so people could push changes there, test them internally
and work out any problems.  We could then move them over to _2_4 quickly
when the changes were stable.  Unfortunately, people started giving out the
_2_5 tree and telling people to use it.

So, to solve that problem I created _2_4_devel so that we could get outside
testing and let users chose which kernel they wanted (brand-new features or
very stable and tested).

Unfortunately we need multiple trees since branches won't do the job for
us.  Lines of development will, though.  The people at BitMover and working
on that feature of BitKeeper for us already.

} It had 6750 support, and 2_4 didn't. I don't see why this
} situation would ever be created, but anyway, clearly 2_5
} was the better tree until it disappeared.
}
} If you need to do experimental work without disturbing the rest
} of the 2_4 code, you should be able to create a branch.

It wasn't a public tree, it should have stayed internal.  I did allow
outside access since all the developers except me are outside FSMLabs.
No-one was supposed to tell people to use it.  Often, it doesn't even
compile.  It's very experimental.  We're in the process of moving over the
code from that tree to the linuxppc_2_4_devel tree so no changes will be
lost.

} 1. why was there a public tree that was not "for outside use"

linuxppc_2_4 is a testing area before sending patches to Linus.  I never
want to have to revert a patch I've sent to Linus because it wasn't tested
and stable (Linus rarely takes patches as it is, I don't want to waste his
bandwidth).  linuxppc_2_4_devel is a working space before changes go to
linuxppc_2_4.

All changes that are stable and useful go to Linus in the end.  Not before
being tested and getting a good "beating around" first, though.

} 2. how can you have two trees, neither of which is a dead end?

When the real 2.5.0 comes out (when Linus creates it) I'll create another
tree, linuxppc_2_5.  I made a mistake in naming our experimental tree
linuxppc_2_5, this tree will be the real linuxppc_2_5.  We'll probably have
a linuxppc_2_5 and linuxppc_2_5_devel but that's still to be decided (it
will probably be decided by need).

So, I think that your short-term goal is to get the 6750 working, right?
linuxppc_2_4_devel should have what you need but if it doesn't it'll be
coming shortly.  You may also want to push MonteVista if you have a support
agreement with them on this board.

If the linuxppc_2_4_devel tree doesn't work for you let me know what
trouble you're having and I'll try to help.

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

  reply	other threads:[~2001-05-10 23:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-10 18:40 linuxppc_2_5 source tree (and others) Albert D. Cahalan
2001-05-10 18:49 ` Tom Rini
2001-05-10 19:46   ` Albert D. Cahalan
2001-05-10 19:57     ` Cort Dougan
2001-05-10 21:24       ` Albert D. Cahalan
2001-05-10 23:11         ` Cort Dougan [this message]
2001-05-11  2:31           ` Murray Jensen
2001-05-11  3:14             ` Cort Dougan
2001-05-11  5:43               ` Murray Jensen
2001-05-10 21:44     ` Tom Rini
2001-05-13 19:33       ` Ira Weiny
2001-05-15  1:40         ` Cort Dougan
  -- strict thread matches above, loose matches on Subject: below --
2001-05-10  8:38 Murray Jensen
2001-05-10 16:10 ` Tom Rini
2001-05-10 16:24 ` Dan Malek
2001-05-10 19:33 ` Cort Dougan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010510171114.C1595@ftsoj.fsmlabs.com \
    --to=cort@fsmlabs.com \
    --cc=Murray.Jensen@cmst.csiro.au \
    --cc=acahalan@cs.uml.edu \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=trini@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).