possible scm change for busybox dev

Bernhard Fischer rep.nop at aon.at
Mon Jun 12 19:55:19 UTC 2006


On Mon, Jun 12, 2006 at 03:19:11PM -0400, Rob Landley wrote:
>On Monday 12 June 2006 1:32 pm, Erik Hovland wrote:
>> On Mon, Jun 12, 2006 at 11:25:20AM -0400, Rob Landley wrote:
>> > (In the long run, I'm pondering switching to something like git so
>> > clashing patches don't bring everything to a halt until the next time I'm
>> > connected to the net...)
>>
>> If developers are specifically being sloppy about checking in, then
>> there is not going to be a fix for this problem if you allow the same
>> people to push to your public git repo.
>
>There's no coordination between developers at all.  (Erik's way of working and 
>my way of working are different.)
>
>> I would say that there needs to be some address of workflow for all devs
>> instead of an scm change If you adopted a workflow that was much like
>> the linux kernel's workflow, then git would probably be right.
>
>The linux kernel's workflow is that Linus pulls, and thus there isn't a single 
>change that goes into Linus's tree that he didn't put there, and never has 
>been.
>
>I inherited a situation from Erik where there are a bunch of developers who 
>are used to checking whatever they feel like directly into the tree in the 
>absence of any maintainer at all, without any sort of coordination or warning 
>or anything.  And when I didn't do the -stable releases like that, some of 
>them got deeply indignant.  (I didn't care.)
>
>Unfortunately, the situation actually tends to slow me down tremendously, 
>because every time I sit down to address the patch backlog I find out that 
>random unrelated changes have already been made to the tree and I have to 
>stop and look at those instead of doing what I was preparing to do.  I 
>prepared a patch series over the weekend (like the kernel's "x of y" chains), 
>and found out that the very first patch was blocked by changes that had 
>occurred to the tree in my absence, at which point I gave up and went to bed.
>
>> That may be easy seeing as Bernhard seems to behave a lot like Andrew
>> Morton.

Not really.
>
>Preparing a bunch of patches to feed into my tree?  Not really, no.

The kernel is maintained in a monolitical manner. One person can write,
everybody else can not.

The repository as it is now is setup so that several people can write.

Rob is usually not (having the time or interrest or whatever) applying
other peoples stuff nowadays. I ment to try to help get bugs fixed and
bugfixes applied so we could have a nice release. Rob usually is not
looking at the bugtracker, and if he is, he _seems_ to ignore most of
the stuff in there. There are plenty of bugs about mount and sort, both
of which he knows better than i do, so i won't look at those, but leave
them to him.
Looking through the rest was something i did in order to help and not to
disturb anyones patch-sets.
>
>> Although I would say the Rob is actually better at reigning in 
>> development then Linus is.
>
>Saying no I'm good at.
>
>> Having said that, I have enjoyed using git for other projects and would
>> not consider it a bad choice.
>>
>> Just in mentioning. Subversion has efficient branching (unlike cvs), you
>> may be able to use that and a different merging workflow to get what you
>> need out of an scm.
>
>I don't really get to do much independent development anymore.  Ever since I 
>took a day job, I barely have enough time to keep up with all the email and 
>patches people send me.  Reviewing and merging other people's patches is 
>pretty darn time consuming.  Having to stop what I'm working on to deal with 
>the tree changing out from under me basically makes it impossible to do 
>anything else...

I honestly do not know what you are referring to there. Your last
checking was r15341. the diffstat between r15341 and r15363 looks like
this:

 Makefile                        |    4 
 Rules.mak                       |   14 +-
 archival/dpkg_deb.c             |    4 
 archival/rpm.c                  |    2 
 coreutils/Config.in             |    4 
 coreutils/echo.c                |  153 ++++++++++++++++++++--
 coreutils/test.c                |  123 +++++++++++------
 debianutils/Config.in           |    9 +
 debianutils/start_stop_daemon.c |  106 ++++++++-------
 editors/vi.c                    |    4 
 include/busybox.h               |    1 
 include/libbb.h                 |    1 
 include/usage.h                 |    4 
 libbb/Makefile.in               |    2 
 libbb/bb_echo.c                 |  151 ---------------------
 libbb/get_line_from_file.c      |   23 ++-
 networking/tftp.c               |  276 +++++++++++++++++++---------------------
 scripts/config/mkconfigs        |    4 
 shell/Config.in                 |   62 ++++----
 shell/ash.c                     |   30 +++-
 20 files changed, 525 insertions(+), 452 deletions(-)

In my POV this is touching 12 source files while the tree consists of
about 580 source files.
Remember how you said we should hold off the passwd stuff because you mean
to look at it? If you want to lock an area, then imho just say so (and
release it upon completion; Is your looking at the password stuff
finished? AFAICT no, you still hold that lock).

I closed about 10 bugs or so, sorted out some duplicates. I'm not too
keen on fooling around with the bug-thing, so i can of course leave all
of them to you, if you prefer.

Also, if i send patches to the list for comments, there is usually no
productive discussion about the stuff i intend to change or the way i
propose. Due to this lack, i normally leave patches locally, wait some
time and then question/revisit the change and only then apply the stuff
to the repository.
If patches or proposals merely get ignored (resp. receive no reaction)
for a long time (more than let's say 2 or 3 weeks), then they are
usually just lost which is an unfortunate situation.
>
>> The OE project has used monotone with some success. My main problem with
>> both subversion and monotone is a lack of cherry-picking feature. Which
>> is probably the most powerful feature of git. But your current workflow
>> does not seem to require it much.
>
>I gave up on being able to cherry pick.  If I don't respond fast enough, one 
>of the other people with svn commit access will just check their own version 
>into the tree, whether I want it in there or not.
>
>This is the situation I inherited.  I never would have set it up this way...
>
>> Just food for thought.



More information about the busybox mailing list