The direction linux is taking

The direction linux is taking

Post by Russell Kin » Sat, 29 Dec 2001 02:00:18




> Tridge wrote the system you describe, several years ago. Its called
> jitterbug but it doesnt help because Linus wont use it

Speaking as someone who _does_ use a system for tracking patches, I
believe that patch management systems are a right pain in the arse.

If the quality of patches aren't good, then it throws you into a problem.
You have to provide people with a reason why you discarded their patch,
which provides people with the perfect opportunity to immediately start
bugging you about exactly how to make it better.  If you get lots of
such patches, eventually you've got a mailbox of people wanting to know
how to make their patches better.

I envy Alan, Linus, and Marcelo for having the ability to silently drop
patches and wait for resends.  I personally don't believe a patch tracking
system makes life any easier.  Yes, it means you can't loose patches, but
it means you can't accidentally loose them on purpose.  This, imho, makes
life very much harder.

I hope this makes some sort of sense 8)

--

             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Alan Co » Sat, 29 Dec 2001 02:50:12


Quote:> I envy Alan, Linus, and Marcelo for having the ability to silently drop
> patches and wait for resends.  I personally don't believe a patch tracking

I go to great lengths to try and avoid that. People often get very
short replies but I try to make sure if the patch isnt queued to apply
they get a reply. Sometimes I have to sit on them for a week until I
understand why I don't like them.

The things I happily drop are people arguing about why I dropped their patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Alan Co » Sat, 29 Dec 2001 02:50:13


I have a system I am happy with, I save stuff that looks worth applying into
a TO_APPLY directory then merge it in logical chunks.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Dave Jone » Sat, 29 Dec 2001 03:10:14



> Sure, although I post to l-k a URL and ChangeLog, and separately send
> to Linus/Marcelo the actual patch. People grumble when I send kiB's
> (or even kB's :-) to the list.

Good enough. (In fact, preferable imo, as long as the patch stays
at the url if still relevant/unapplied).

The "I sent a patch n times to linus without ccing l-k and he didn't
apply it" case however, is a lost one imo.

Dave.

--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Dave Jone » Sat, 29 Dec 2001 03:40:10



> This is absolutely true - it's a _very_ powerful thing. Old patches
> simply grow stale: keeping track of them is not necessarily at all
> useful, and can add more work than anything else.

*nod*, until they get scooped up into another tree -ac, -dj, -whatever
and fed to you whenever you're in the mood for resyncing.

Quote:> This is not about technology.  This is about sustainable development.
> The most important part to that is the developers themselves - I refuse
> to put myself in a situation where _I_ need to scale, because that would
> be stupid - people simply do not scale.  So I require others to do more
> of the work. Think distributed development.

Absolutely. When I decided to take on carrying the 2.4 patches in sync
with 2.5, I knew I was undertaking something of no small order.
Scooping up forward port patches, and silent-drop bits from l-k
is almost a full time job in itself when yourself and Marcelo release
kernels in quick succession 8-)

And when you're ready to resync what I've got so far (currently ~3mb),
it's going to be another full time job splitting it into bits to feed
you linus-bite-sized chunks. (ObSidenote: When this time comes btw,
if maintainers of relevant parts want to feed Linus their relevant
parts from my tree, that would be appreciated, and would keep _my_ load
down :-)

Quote:> We've seen this several times in Linux - David, for example, used to
> maintain his CVS tree, and he ended up being rather frustrated about
> having to then maintain it all and clean up the bad parts because I
> didn't want to apply them (and he didn't really want me to) and he
> couldn't make people clean up themselves because "once it was in, it was
> in".


I went on xmas vacation. Did I miss something ?

Dave.

--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Rik van Rie » Sat, 29 Dec 2001 05:10:09



> If you get this working nicely, it might even be a generally useful
> thing. A set of perl scripts and easy interface commands could prove
> popular. I would certainly find it convenient to have a patch
> retransmission system that re-sent patches every time a new pre-patch
> came out, and emailed me when the patch no longer applies.

... or compiles, or applies with an offset

Quote:> If it could automatically de-queue when the patch is applied, or when
> I manually remove it, that would be even better.

... or when somebody replies to the patch and the reply
gets caught by a program invoked from your .procmailrc

If Linus replies he has seen the patch, don't keep
bombing him.

Of course when the patch gets dequeued, the program should
send you a mail with the reason.

Quote:> And if I make an update to a queued patch, it obsoletes the old one,
> that would be good too.

Good one, this needs to be added.

Any more requirements / ideas / volunteers / ... ?

(and remember, this thing is designed to make Linus his life
easier, too)

regards,

Rik
--
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/             http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Dana Lacost » Sat, 29 Dec 2001 05:50:11


Quote:> But this didn't answer my question at all.  My question was
> why is this a
> problem related to a source management system?  I can see how
> to exactly
> mimic what described Al doing in BK so if that is the
> definition of goodness,
> the addition (or absence) of a SCM doesn't seem to change the answer.
> I _think_ what you are saying is that an SCM where your
> repository is a
> wide open black hole with no quality control is a problem, but that's
> not the SCM's fault.  You are the filter, the SCM is simply
> an accounting/
> filing system.

<deletia>

Quote:> but your typical SCM has the end user doing the merges, not
> the maintainer.
> If you had an SCM system which allowed the maintainer to do
> all or some of
> the merging, would that help?

i think the problem becomes one of usability : is there any
way that the SCM system can be easy enough to use?

or, put another way :
why use the SCM if the features it gives are being supplied
in a completely acceptable manner by the maintainer?
If Linus is doing it on his own, and you're suggesting that
he set the SCM up so that he does it all on his own in the
end anyways, why should he add an extremely obtrusive step
(SCM) to the mix?  Why should it be any harder on his day
to day methodology that he's already comfortable with?

If SCM is just a distribution mechanism, then it's not
something that's particularly interesting.  If SCM is
only allowing a single user to apply patches, then it's
not particularly useful in reducing the workload of that
person (if they've got the organizational skills to manage
the whole thing, then adding another layer to work through
isn't going to help!)

Don't get me wrong, I'm all for SCM, I just don't think
that applying SCM is going to relieve any patch-confusion
and it's not going to add any real benefit either....

(If, on the other hand, we allowed multiple committers
and access-controlled maintainer lists, then SCM would
be beautiful!  but this isn't FreeBSD :) :) :) :) :)

/me ducks for that last comment

Dana Lacoste
Ottawa, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Oliver Xymoro » Mon, 31 Dec 2001 02:20:09



> So even if I used CVS or BK internally, that's not what people _gripe_
> about.  People want write access, not just a SCM.

Not true. I for one want to do a 'cvs update' to get current and be able
to look at revision logs and keep my own branches and merge them onto the
tip.  Sure, I can do this manually, but an SCM makes this quite a bit
easier.

Other useful tools are things like CVS blame:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/Makefile.in

(not sure how this would be done with single user check-in, but there's
probably a way to hack it in)

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Larry McVo » Mon, 31 Dec 2001 02:30:09



> Other useful tools are things like CVS blame:

> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/Makefile.in

> (not sure how this would be done with single user check-in, but there's
> probably a way to hack it in)

We love the "blame" (aka annotate) feature and took it to a new level.
As an old coworker once said of SCM: "You can run, but you can't hide" :-)

We give you every possible variation of annotate in BK.  You can see the
annotated listing of any version of a file, and you construct arbitrary
versions of files.  The most useful one [1] is "show me the annotated
listing of all lines that have ever been in any version of this file".

You can also grep for stuff in the revision history.  From the man page [2]:

       To see if <pattern> occurs anywhere in any version of  any
       file of your tree:

           $ bk -r grep -R pattern

       To see if it occurs anywhere in the most recent version of
       of any file of your tree:

           $ bk -r grep pattern

       To see if it was added by the most recent delta made in of
       any file of your tree:

           $ bk -r grep -R+ pattern

[1] http://www.bitkeeper.com/manpages/bk-annotate-1.html
[2] http://www.bitkeeper.com/manpages/bk-grep-1.html
--
---
Larry McVoy              lm at bitmover.com           http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Larry McVo » Mon, 31 Dec 2001 04:40:10


[patchbot stuff]

I normally stay out of these discussions because whatever I say usually
gets taken as "he's just promoting BitKeeper" but I think a point needs
to be made.  I promise not to mention BK.

One thing that people seem to be ignoring is that patches tend to need
to be merged.  The only way that can not be true is if the baseline is
revved every time a patch is applied, people get the new baseline before
they send in a patch.

If you have N people trying to patch the same file, you'll require N
releases and some poor shlep is going to have to resubmit their patch
N-1 times before it gets in.

If you look at this carefully, you'll see that in order to have an automated
system, you must serialize all development which touches the same files
(or the same areas in the same files if you are willing to automerge,
but automerging outside of an SCM is difficult to say the least).

I think this is basically why systems like what is being proposed fizzle
out; it's certainly come up over and over.  The world wants to work in
parallel (think "1000's of Linux developers world wide", yeah, it's BS
but there are certainly a couple hundred).  Forcing people to work in
serial isn't the answer.

One way to quantify this is to ask Linus, Alan, Marcelo, et al, how much
time they spend merging, i.e., how often do they get patch rejects?
Regardless of the answer, it will be interesting.  If it is a lot,
then the patchbot idea has marginal usefulness.  If it is none at all,
then that says development is serialized, which means we may be leaving
a lot of progress on the floor.

I wouldn't be surprised if the serialized case is the answer, or close
to it.  It's rare that I hear Open Source leaders complain about merging,
which suggests fairly serialized processes.  In the commercial world,
there is a ton of parallel development and merging is about 90% of what
people do when they are interacting with the SCM system.  Checkin accounts
for about 8%, and after that it's all over the place.

Anyway, I'm interested to see if there are screams of "all I ever do is
merge and I hate it" or "merging?  what's that?".
--
---
Larry McVoy              lm at bitmover.com           http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Alan Co » Mon, 31 Dec 2001 08:00:11


Quote:> to filter subjects with [PATCH] and the likes into an additional
> folder.  Every so often, I'll go through it, deleting ones that
> ended up getting merged with mainline.

Right. Its probably worth noting that I do the same and I think Linus does
because he's certainly asked me to put PATCH in the subject line before.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Dave Jone » Mon, 31 Dec 2001 08:10:12



> Most mangled diffs I get are caused by pine. Fixing pine would do more
> wonders than any magical patchbot.

The 'kill trailing spaces on each line' bug ? That has been fixed since
4.31 or so.  Or are there other evils lurking ?
I change between mutt & pine depending on position of the moon,
and thats the only bug that I'm aware of that yourself (and Linus)
have said "Resend with a non-borked mua"

Dave.

--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

The direction linux is taking

Post by Larry McVo » Mon, 31 Dec 2001 08:40:14



> > Is it really true that there are any significant number of patches
> > submitted that don't even compile?

> No

OK, so there are no significant numbers of patches that the patchbot will
eliminate, by your admission.  So what's the point?  What is the problem
you have solved?  And where's the code?  This sounds like you have whittled
it down to a cgi-script of about 100 lines of perl.  How about building it
and demonstrating the usefulness rather than telling us how great it is
going to be?
--
---
Larry McVoy              lm at bitmover.com           http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

The direction linux is taking

Post by Arnaldo Carvalho de Mel » Mon, 31 Dec 2001 08:50:10


Em Sat, Dec 29, 2001 at 05:33:57PM -0600, Oliver Xymoron escreveu:



> > > > The 'kill trailing spaces on each line' bug ? That has been fixed since
> > > > 4.31 or so.  Or are there other evils lurking ?
> > > Thats the beast. Last time I looked it was fixed in some vendor trees

> > Ah, explains why I've not seen it happen for a while.

> > > but the official pine people were refusing to take it

> The vendors shouldn't even have their own trees according to the license.

heh, this is getting way off-topic, but last time I checked one can ship
pine with patches if the resulting package has an 'l' at the end, e.g.
pine-4.31L.i386.rpm

Quote:> > *sigh*
> > Another reason to be a mutt advocate I suppose 8)

> Don't kid yourself, Mutt's a pile of *too. And not an alternative for
> 99% of Pine users.

Hey, I'm one of the 1% then, switched from pine one year ago and I'm happy
with mutt.

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

The direction linux is taking

Post by Oliver Xymoro » Mon, 31 Dec 2001 09:30:11




> > > > > Is it really true that there are any significant number of patches
> > > > > submitted that don't even compile?

> > > > No

> > > OK, so there are no significant numbers of patches that the patchbot will
> > > eliminate, by your admission.

> > Except for the ones that get garbage collected after each new kernel
> > release WHEN THE VALIDITY OF THE QUEUE IS RECHECKED.

> Which is how many?  Do you have _any_ data which shows that this is going
> to do anything?

Yes. Every patch that goes by that says 'resynced with kernel x+1'. Which
seems to be a decent fraction of the ones that people care about. And an
ever larger percentage with each release. You've been on the list a few
years, you have the same data I have.

One of the stated problems with jitterbug was that it got cluttered with
stuff that never got kicked off. This is just part of the method of
kicking it off, the other (sigh, would have been nice if you'd read my
original message rather than latching on to a small part of the thread
that followed) was a system for quickly kicking stuff off the queue
manually.

Quote:> Great, so set it up, write a parser that grabs all the patches out of the
> list, run them through your system, and report back how much it helps.

My impression is that quite a bit of stuff (the majority?) never shows up
on the list at all, being fed directly to maintainers. And I obviously
can't say much about the manual reject side of things, not being Linus.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. The direction linux is taking

Why does'nt linus keep his sources in a cvs tree
so the rest of the folks can read it from there ?

he can still have the write access to the tree
exclusively.

We can keep patches in some kind of database as well
so they dont get lost, linus can mark them rejected/applied
e.t.c e.t.c.

Just thinking aloud.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. 2.5 x86: TeX binaries?

3. memory limitations per process

4. sed not taking [\t]+ tho it takes [\t]*

5. Netscape Enterprise Server Problems...HELP!

6. Linux' mission (Re: Linux - Going in the wrong direction?)

7. Laptop recommendations x86 Solaris?

8. This clone thing...am I stupid, or am I right?

9. I am with the following error, when i am running lilo...

10. Am I touchy? Or am I right?

11. Am I seeing IPv5, or am I hallucinating?