gcc branches?

gcc branches?

[Per Bothner]

Any ETA on when the gcc trunk will be open again for
non-bug-fixes?  I've got two space-reduction patches
I'd like to check in soon, and I'm trying to figure out
whether to check in to the 3_4-basic-improvements-branch
or wait until the trunk is open.

Will someone automatically merge in changes from the 3.4
branch into the trunk, or are each of us responsible for
our own merges?  I hope the former, though if there are
any conflicts that may be difficult.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: gcc branches?

[Zack Weinberg]

Per Bothner <per@bothner.com> writes:

> Will someone automatically merge in changes from the 3.4
> branch into the trunk, or are each of us responsible for
> our own merges?  I hope the former, though if there are
> any conflicts that may be difficult.

I have been doing trunk->branch merges all along, and I intend to
merge the entire branch back to the trunk at once, shortly after the
3.3 branch is created.  It will need testing though.  (I've got x86,
sparc, and hppa test platforms lined up; other architectures would be
helpful.)

zw

Re: gcc branches?

[Per Bothner]

Zack Weinberg wrote:

> I have been doing trunk->branch merges all along, and I intend to
> merge the entire branch back to the trunk at once, shortly after the
> 3.3 branch is created.  It will need testing though.  (I've got x86,
> sparc, and hppa test platforms lined up; other architectures would be
> helpful.)

Great!  Have you (or Mark?) tested merging the 3.4 branch with the
cp-parser-branch, since (I gather) we'll be merging that in too
as soon as the trunk opens up?
--
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: gcc branches?

[Zack Weinberg]

Per Bothner <per@bothner.com> writes:

> Zack Weinberg wrote:
>
>> I have been doing trunk->branch merges all along, and I intend to
>> merge the entire branch back to the trunk at once, shortly after the
>> 3.3 branch is created.  It will need testing though.  (I've got x86,
>> sparc, and hppa test platforms lined up; other architectures would be
>> helpful.)
>
> Great!  Have you (or Mark?) tested merging the 3.4 branch with the
> cp-parser-branch, since (I gather) we'll be merging that in too
> as soon as the trunk opens up?

Not to my knowledge.  Mark's been playing that branch close to his
chest.

zw

Re: gcc branches?

[Tom Lord]

The following exchange is typical of many that cross the gcc list, and
thus, at least iconically, it represents a lot of people's time and
money.


   per:
   > Any ETA on when the gcc trunk will be open again for
   > non-bug-fixes?  I've got two space-reduction patches
   > I'd like to check in soon, and I'm trying to figure out
   > whether to check in to the 3_4-basic-improvements-branch
   > or wait until the trunk is open.

   > Will someone automatically merge in changes from the 3.4
   > branch into the trunk, or are each of us responsible for
   > our own merges?  I hope the former, though if there are
   > any conflicts that may be difficult.


   zack:
   > I have been doing trunk->branch merges all along, and I
   > intend to merge the entire branch back to the trunk at once,
   > shortly after the 3.3 branch is created.  It will need
   > testing though.  (I've got x86, sparc, and hppa test
   > platforms lined up; other architectures would be helpful.)


If the project was using `arch', I think you'd have an easier time.

Since it is cheap and easy to create branches (spanning repositories),
you (per) would have the option of forking the trunk and committing
your changes there.  By hand, or (better), automatically given some
infrastructure work first, as the trunk evolves, you could have the
evolving trunk re-merged nightly with your changes so that any
conflicts are noticed early, giving you some flexibility about when
you fix them (or about who fixes them).  When the freeze is off,
merging the changes back to the trunk would go smoothly.  (Of course
you can do similar things using any revision control system, arch
simply makes it easier than most and is designed with infrastructure
automation in mind.)

I've been thinking it makes sense to automate things as follows
(though feedback from gcc developers might change my mind):  

*) developers have their own repositories

  Particularly, developers working on new features rather than those
  doing release integration/engineering.  One advantage of this is
  that each feature developer can work on a branch of the trunk, using
  `star-merge' as described above, to catch conflicts as early as
  desired.  Another advantage is that feature developers can decide to
  merge their branches with one another early, simplifying integration
  into the trunk down the road -- shortening freeze periods.  Another
  advantage is that early adopters of features can gain access to them
  earlier, more easily.


*) the gcc web site catalogs all those repositories

  You can browse and review features under development, for example.
  You can get email notifications as a feature evolves.  You can run a
  cron job that will detect (early) when two features-in-progress
  touch overlapping files and are likely to conflict.  These features
  can be offered even to developers who do not have write access to
  the primary repository.


*) favored developers get automated testing

  By adding a header field to some of your log messages, you can
  trigger overnight testing of your branches.  This facility can be
  safely extended even to developers who do not have write access to
  the primary repository -- and in that way, it can reduce the
  workload on those who do have write access and have the job of
  merging in other people's patches.


*) trunk merges get automated vetting

  By adding a header field to some of your log messages, you can 
  declare that a branch is ready to be merged into the trunk.  
  This implies, for example, that you have resolved all conflicts
  on your branch -- that if the trunk remains stable, the merge will
  be clean.  Automatically, then, the merge can be validated and
  tested before, finally, being committed to the trunk.

  Of course, if two developers publish conflicting changes at the same
  time, human intervention is necessary for at least one of those
  change sets -- but here, too, arch can help: by helping to
  automatically detect the condition, to notify the relevant
  developers, and to provide them with good tools for fixing the
  conflicts.


I also note that "CVS is wedged" posts occur frequently on the gcc
list.  With a modest up-front investment to finish `arch 1.0' and test
the heck out it, I think it is clear (from the designs of both
systems), that arch's admin costs will be lower -- repositories will
break less often (and perhaps, essentially, never).  There has been
some sentiment on this list to move to svn -- I encourage design
inspections and comparisons (contemplating admin costs and robustness)
there as well.

Finally,


   per:
   > Great!  Have you (or Mark?) tested merging the 3.4 branch
   > with the cp-parser-branch


Such testing is straightforward to automate with arch and a status
inquiry like this one should be answered by automatically generated
web pages.


-t

Re: gcc branches?

[Per Bothner]

 From what I hear, arch is a much more visisionary and conceptually
powerful framework.  However, the "engineering" is lacking.  So we
have a choice between:
* Sticking with CVS.
* Switching to Subversion, once it is solid enough.
This is basically an "improved CVS".
* Switch to arch (after making it suitable).
* Switch to bitkeeper (not an option for gcc).

So the choice (in say a year or so) is between subversion or arch.
I suspect it will be subversion, just because subversion has had more
resourches put into making it a solid, eficient, maintainable and
"production quality".

It would be nice to make arch equally "production quality", but
that takes a lot of work.  I hope you can find volunteers to do
that work.  Perhaps "stealing" as much code from subversions may
be worth considering.  I.e. merge the ieads of arch into the
framework of subversions?  (I say this without know either code-base,
so it probably doesn't make sense.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: gcc branches?

[Tom Lord]

The following was initially the concluding paragraph, but since I 
think it is the most important, let me lead off with it:

`arch' is fun, cool, interesting, simple, and has a clear path to
making your and lot of other people's lives better.  So let's get off
the posing and resume being hackers -- please dig into it -- I predict
you'll come to dig it.  We'll find a way to solve the funding problems
as we go along.

Regards,
-t



And, true to form, here's the vitriol


       When one or both get to the stage that they are serious
       contenders to replace cvs, then I'd like someone whose
       judgement I trust (it could be me, I guess) to evaluate both.


The situation is more complicated than that.

`arch', unless something changes, will _not_ reach that stage.  In
spite of your protests, I think you are in a position to help fix
that.

`arch' _could_ reach that stage, for less money than svn by my
estimation, and producing a far better end result (that is much
needed).  And this is fairly easy to determine, if you look into it in
reasonable depth.

So I must, unfortunately, ask people such as you to put their
momentary convenience aside, and do a little planning and looking
ahead in this area.  Is not GCC engineering process a legitimate
concern of the SC?


    But until then, I think it is premature or either myself or the
    gcc steering committee to spend much time evaluating them (unless
    personally interested, of course).

If you stick to that, you are doing the community, the market, and the
free software movement a disservice.   Surely planning is an important
function of the SC.  Surely you recognize that effective
(i.e. proactive, positively consequentlal) planning is important at
this juncture.


     Convincing me won't really help you or arch.  I'm not an opinion-maker
     in the [presumably relevant part of] Free Software world.  

Hopefully this is false, given your SC membership.  If it is not, then
I think it is time to ask some questions about what your duty as an SC
member is -- and about the role of the SC overall.
     


     If I were, I'd be rich from Kawa - which a very few people rave
     about.

Surely you aren't asking for a project-endorsement quid-pro-quo.
Actually, not "surely" at all -- one can see such q-p-q's operational
elsewhere -- so why not here, eh?

Really, I can't begin to fathom how Kawa enters into this discussion
at all, unless as a possible implementation language for an `arch'.

In general, your modern western euro royalist approach to SC duties
("deserving infinite deference, yet responsible for nothing") is, to
put it lightly, disheartening.

Regards,
-t

Re: gcc branches?

[Tom Lord]

	per:

	> (I say this without know either code-base, so it probably
	> doesn't make sense.)

That's a bug.  If you ask focused questions, I will be happy to answer
them.  It shouldn't take very many hours to grok the situation.  In
person, I'd bet it would take one or two (since I recall you as being
smart/competent).  Do you like good beer?



	> [From what I hear] the "engineering" [in `arch']
	> is lacking.

Yes, well, bullshit rumours are like that.

Ask some serious questions or read the `arch' source code.  I'll be
happy to help with your evaluation because I am confident that if you
are not foolish about it, I'll "win".

I can also help a little bit by providing some critical perspective
about svn.

-t

Re: gcc branches?

[Per Bothner]

Tom Lord wrote:
> That's a bug.  If you ask focused questions, I will be happy to answer
> them.  It shouldn't take very many hours to grok the situation.

It wouldn't do much good, since I'm not in a position to either
finance or recommend either svn or arch.  When one or both get to
the stage that they are serious contenders to replace cvs, then
I'd like someone whose judgement I trust (it could be me, I guess)
to evaluate both.  But until then, I think it is premature or
either myself or the gcc steering committee to spend much time
evaluating them (unless personally interested, of course).

> 	> [From what I hear] the "engineering" [in `arch']
> 	> is lacking.
> 
> Yes, well, bullshit rumours are like that.

Perception rules, often. Overcoming incorrect perception is
possible, but takes a lot of work.

> Ask some serious questions or read the `arch' source code.  I'll be
> happy to help with your evaluation because I am confident that if you
> are not foolish about it, I'll "win".

Convincing me won't really help you or arch.  I'm not an opinion-maker
in the Free Software world.  If I were, I'd be rich from Kawa - which
a very few people rave about.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: gcc branches?

[Per Bothner]

Tom Lord wrote:
> The following was initially the concluding paragraph, but since I 
> think it is the most important, let me lead off with it:
> 
> `arch' is fun, cool, interesting, simple, and has a clear path to
> making your and lot of other people's lives better.  So let's get off
> the posing and resume being hackers -- please dig into it -- I predict
> you'll come to dig it.  We'll find a way to solve the funding problems
> as we go along.

Fine.  However, I personally have my own "fun, cool, interesting"
project(s) that I'm already working on, or that I want to work on.
The same applies to many of us, or we have no time/interest hacking
on new projects after our days jobs.

> `arch', unless something changes, will _not_ reach that stage.  In
> spite of your protests, I think you are in a position to help fix
> that.

Other big projects have managed to become solid and useful using
people's spare time.

> So I must, unfortunately, ask people such as you to put their
> momentary convenience aside, and do a little planning and looking
> ahead in this area.

You can ask it, but you cannot expect it.

> Is not GCC engineering process a legitimate
> concern of the SC?

No, it is a legitimate concern of the entire gcc community.  It is
*not* the SC's job to initiate, lead, or fund projects.  It is the
SC's job abjudicate between competing proposals, if the technical
leadersship (a mcuh less formal group of people) do not agree.

> If you stick to that, you are doing the community, the market, and the
> free software movement a disservice.

The Free Software movement will just have to manage.  We've all done 
plenty for it, and can't do everything.

> Surely planning is an important function of the SC.

Only to a very limited extent.  Since we have no means of
enforcement or sources of funding, and depend entirely on
volunteers, it is limited what planning can do.

> Surely you recognize that effective
> (i.e. proactive, positively consequentlal) planning is important at
> this juncture.

It may be important, but I don't think it's going to happen.
We tend to be more re-active.

I'd love to have a "Gcc Foundation" (within the FSF of course) that had
a real budget, and real plans.  I believe this has been tried before,
and may yet succeed.  But I don't have the time, skills, or inclination
to do all the politicking needed.

>      Convincing me won't really help you or arch.  I'm not an opinion-maker
>      in the [presumably relevant part of] Free Software world.  
> 
> Hopefully this is false, given your SC membership.

The SC as a whole may have name recogniztion and influence comparable
to (say) Larry Wall or Linus Torvalds.  Individually, none of us have
anywhere close to that level.  That's a fact.  Many of us do have a
fair level of name recognition and respect.  People will talk with us,
but that doesn't mean they will give us money.  Remember, we are still
in a recession.  Discretionary spending is very hard to "sell".

> If it is not, then
> I think it is time to ask some questions about what your duty as an SC
> member is -- and about the role of the SC overall.

Ask ahead.  Change requires someone with the will and energy to do
better/different.

Setting up a more pro-active "foundation" has been tried.  That doesn't
mean it can't succeed or shouldn't be tried again.

>      If I were, I'd be rich from Kawa - which a very few people rave
>      about.
> 
> Really, I can't begin to fathom how Kawa enters into this discussion
> at all, unless as a possible implementation language for an `arch'.

It was an example of an established project close to my heart that has
technical superiority (I and others think) and happy users, but I still
can't raise enough money for it to pay myself a decent wage.  So while
you have my sympathy, I can't offer you more.

> In general, your modern western euro royalist approach to SC duties
> ("deserving infinite deference, yet responsible for nothing") is, to
> put it lightly, disheartening.

You're free to start a revolution.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: gcc branches?

[Tom Lord]

	    >> Surely planning is an important function of the SC.

	    > Only to a very limited extent.  Since we have no means
	    > of enforcement or sources of funding, and depend
	    > entirely on volunteers, it is limited what planning can
	    > do.

Right.  I recognize that.  SC legitimacy is historically meritocratous
although there is a tiny bit of practical authority originating out of
the distribution of CVS and web site passwords.   Mostly it was the
EGCS foo and subsequent nearly-monotonic improvments to GCC that give
the SC its standing.  Y'all seem to be proud of that and that seems
appropriate to me.

What comes after that success?

Some of the volunteers the SC works with are corporations and part of
their contribution is funded work.  I think it's legitimate for the SC
to approach those companies about how to make their spending more
efficient for them, and more effective for gcc as a whole.  The SC is
far better positioned, politically, than I or any other individual to
have that kind of conversation with those volunteer corporations.

If you have some individual volunteers that want to make a long-term
quasi-commitment to your project, it's customary to give some guidance
about what work needs doing -- not just a task list, but a real
negotiation/planning session that helps to produce a task list.  The
corporations are volunteers who are making long-term quasi-commitments
to spend a decent amount of money on GCC.


	> Remember, we are still in a recession.  Discretionary
	> spending is very hard to "sell".

Many business leaders/educational materials, etc. will tell you that
during a recession, R&D spending and marketing are the two things you
want to protect and even increase.  It's part of how recessions get
fixed.  Canceling product lines that aren't going to make it, forming
mergers, tuning productivity gains -- those are the ways to align
spending to reduced revenue.



	> I'd love to have a "Gcc Foundation" (within the FSF of
	> course) 

I proposed that a while back and the feedback was almost universally
negative.  I think it strikes people as too much like socialism, or
something: there's a definate resistence to handing over substantial
budgets to NPOs.  There is something appealing about the companies who
fund much of GCC spending their own money directly.  People like
capitalist freedoms.

So I'm not proposing a big SC budget today.

Here's an analogy to what I'm proposing: let's suppose it was the
80s and GCC was an in-house project at a large vendor.  Let's suppose
that GCC had a small team of project-leads from various divisions --
the SC -- who held engineering, not management titles (i.e., they have
little or no budgets).  In that circumstance, it would be quite
ordinary and useful for the project leads to suggest plans and
budgeting strategies to the managers, and for that to be an important
factor in how budgeting happens.  Since the project spans divisions,
there'd be some politics among the managers to figure out which
budgets provide what parts of the funding -- but the SC would be
providing project-perspective guidance about how to coordinate that
budgeting.

Now, GCC isn't an in-house project, and the management in question
doesn't span divisions -- it spans companies.  But it's still useful
to try to coordinate spending among those managers more directly than
at the level of todo list / patch acceptance / release management.

GCC is interesting in particular because, historically, it is a
"template project" -- a successful commercialization of free software
that people try to emulate with other projects.

That's all very general.  With `arch', it gets a bit more concrete
because what I've been proposing are tools that specifically address
lowering the costs and raising the quality of source-based cooperation
among the volunteers.  That's an issue that is demonstrably useful for
gcc (scan the past year of the dev list on the topics of CVS, testing,
and branch management).   And it's an issue that, if addressed
cleanly, can benefit other projects as well.

In economic theory, the volunteer corporations like projects like GCC
because of the low "transaction costs" for inter-corporate
cooperation.  They should be receptive to plans that reinforce and
improve that, especially if the plans can help other projects as well.
The FSF, meanwhile, likes volunteer corporations because they
contribute useful work: it should be receptive to plans that can
improve the quality and quantity of what volunteer cooperations can do
per dollar spent.



    Fine.  However, I personally have my own "fun, cool, interesting"
    project(s) that I'm already working on, or that I want to work on.
    The same applies to many of us, or we have no time/interest hacking
    on new projects after our days jobs.

While a big SC budget isn't popular, perhaps (as with executive
boards) SC members should receive honorariums or stipends for their
SC activities.




	[Kawa] was an example of an established project close to my heart
	that has technical superiority (I and others think) and happy
	users, but I still can't raise enough money for it to pay
	myself a decent wage.  So while you have my sympathy, I can't
	offer you more.

Ok.  Kawa may be symptomatic of another (related) problem: that the
free software businesses haven't (for the most part) figured out how
to invest in strategic, practical research in any kind of systematic
way.

In general, there's too much "magic cauldron" thinking implicit in how
the industry is relating to free software these days.

Regards,
-t

Re: gcc branches?

[Phil Edwards]

On Fri, Dec 06, 2002 at 11:08:22PM -0800, Tom Lord wrote:
> 	> [From what I hear] the "engineering" [in `arch']
> 	> is lacking.
> 
> Yes, well, bullshit rumours are like that.
> 
> Ask some serious questions or read the `arch' source code.  I'll be
> happy to help with your evaluation because I am confident that if you
> are not foolish about it, I'll "win".

This is why I distrust arch; I distrust the mentality of the authors
behind it.  Anyone who says, "certainly, let's discuss it, and if you aren't
stupid, you'll agree with me," is too arrogant to be bothered to work with.


> I can also help a little bit by providing some critical perspective
> about svn.

So, you're qualified to dispense criticism of /other/ tools, but criticism
of /your/ tool is "bullshit rumor".

Sorry, Tom.  You aren't going to convince me to stop working on GCC and
work on arch instead; I don't have the time or the interest.

I'm pleased with the leadership provided by the SC; they take a light
touch in a community of volunteers.  If I came home from work, sat down to
do some volunteer hacking, and was ordered by an arrogant, heavy-handed,
"you must focus on project <foo> now or else" SC, I would cordially invite
them to perform a certain anitomical impossibility, and take my resources
elsewhere.  I don't believe the SC have the time or the interest to hack
arch code either.  No do they have secret caches of funding.


I'm still trying to figure out what exactly -- concrete suggestions, now --
what exactly you want us to do, given the constraints of a) no extra time,
and b) no money.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

on reputation and lines and putting things places (Re: gcc branches?)

[Tom Lord]

       > Ask some serious questions or read the `arch' source code.
       > I'll be happy to help with your evaluation because I am
       > confident that if you are not foolish about it, I'll "win".

       This is why I distrust arch; I distrust the mentality of the
       authors behind it.  Anyone who says, "certainly, let's discuss
       it, and if you aren't stupid, you'll agree with me," is too
       arrogant to be bothered to work with.

Wow.  That's not what I'm saying.  My bad for casually using the word
"foolish" on a mailing list, I suppose.

I'm saying:

    I already know that you (SC members) are smart.  I already know
    that arch is good and the project is very useful to you.  What's
    been consistently lacking for many months now is a serious
    discussion of the issues and technology domain.  There's a
    communication disconnect, it seems to me.  In this particular
    instance, not repairing that disconnect, will be seen in
    retrospect as foolish.

"foolish" in contexts like this doesn't seem to me to be a personal
judgement about people's competence.  Instead, it's just me, putting
some substantial part of what little good reputation I might have on
the line, explicitly.  It's me saying: I'm not bullshitting here and
I'm not even just speculating -- this is real, and important, and
deserves your focused attention.

I could equally well have said:

	I am confident that if you spend a bit of time digging into 
	these issues -- such that I become confident you really are 
	thinking about the design space and it's implications -- that
	you'll come to agree with me that `arch' is a no-brainer, and
	highly desirable technology for you.

It's a good heuristic for busy project leads to be dismissive by
default.  My "foolish" comment is just stressing my judgement that
this is a case where that default response is inappropriate.  Yes,
yes, I know you don't have time for 99% of anything off your main
track -- I'm insisting that this is in that 1%.  Here, I'll use strong
language (e.g. "foolish"), to demonstrate my insistence.  This is a
bit like that guy (was it Larry Wall?) who (carefully, so as not to
cause injury) threw and smashed a coffee-cup against a wall during a
wet-space meeting -- to signal, unambiguously: "Ok, I'm insisting
now."

So, again: "foolish" in this context is meant to underscore my
confidence -- not to denigrate others.  Where I come from, this
idiomatic usage is common among engineers and understood positively
with a smirk and a "well, ok then".  It's an instance of engineering
machismo functioning properly.  Sadly, it has been my experience that
this elegant use of conversational valence is easily confused with
random email-based flamage.


	So, you're qualified to dispense criticism of /other/ tools,
	but criticism of /your/ tool is "bullshit rumor".

Yes.

Some criticisms (not the ones offered here) of `arch' are not
bullshit.  But neither are they fatal: rather, they are part of why
arch needs just a bit of commercial investment to finish the job.
I have a number of such criticisms myself.  This is part of the transition
from strategic R&D to tactical execution.

Yes, I am quite well qualified to say a thing or two about the
approach being taken by svn.  Under some circumstances, it is my
social duty to speak up.


     I'm pleased with the leadership provided by the SC; they take a
     light touch in a community of volunteers.  If I came home from
     work, sat down to do some volunteer hacking, and was ordered by
     an arrogant, heavy-handed, "you must focus on project <foo> now
     or else" SC, I would cordially invite them to perform a certain
     anitomical impossibility, and take my resources elsewhere.

Well, of course!  I'm not asking the SC to change their relation to
you, an individual.  I am asking them to first, start to understand
`arch' and the related projects I've been advocating and how those
things relate to the project; second, we can start to figure out
together how to relate this to the volunteer _corporations_.

If all goes well, it will become easier for you, as an individual, to
contribute as you like.  Your time is valuable.  `arch' can make
your life more fun, and your contributions more effective.


    I'm still trying to figure out what exactly -- concrete
    suggestions, now -- what exactly you want us to do, given the
    constraints of a) no extra time, and b) no money.

This list is advertised as the best way to communicate with the SC.
The SC is the best way to communicate with the corporations.

"It was uphill both ways.  And we liked it that way.",
-t

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Tom Lord]

       So, again: "foolish" in this context is meant to underscore my
       confidence -- not to denigrate others.


I'd like to add that:

I wish I had had sufficient resources to perfectly prepare the
ultimate presentation of why `arch' is both good and deeply relevent,
and sustain it's presentation on my web site.

I didn't.  So I must request some genuine uptake[*] and professional
courtesy, instead: good conversation is cheaper than perfect
educational materials.  The source, and some reasonably happy users
are available.

-t

[*] "genuine uptake"

   A technical term from feminist philosophy that is hopefully
   comprehensible even when applied outside that context.  Within
   feminist philosophy, it is often used in analysis of the origins of 
   justified anger.

Re: on reputation and lines and putting things places (Re: gcc branche

[Kai Henningsen]

lord@emf.net (Tom Lord)  wrote on 07.12.02 in <200212080151.RAA11578@emf.net>:

> [*] "genuine uptake"
>
>    A technical term from feminist philosophy that is hopefully
>    comprehensible even when applied outside that context.  Within
>    feminist philosophy, it is often used in analysis of the origins of
>    justified anger.

Sorry, reads like Chinese to me, either in or outside "feminist  
philosophy" (which, in itself, sounds like a rather doubtful proposition  
to me).

MfG Kai

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Stan Shebs]

Tom Lord wrote:

>[...] I am asking [the SC] to first, start to understand
>`arch' and the related projects I've been advocating and how those
>things relate to the project; second, we can start to figure out
>together how to relate this to the volunteer _corporations_.
>
You'd do better to find an individual or subgroup who will get excited
about arch, use/improve it, and advocate it to other GCC developers.
IIRC, Larry McVoy got the Linux PPC port folks to start using BitKeeper
first, and then they helped sell it to the other kernel developers.

It would also help to be more specific about how arch will help *me*.
Despite the loose talk about altruism, 99% of GCC developers are really
doing it for selfish reasons - money, fame, joie de hack, scratching
an itch, whatever.  We only cooperate because we can do more working
together than separately.

Now, almost all of *my* merge difficulties have been because Apple
changes to GCC are logically contradictory to FSF code.  Does arch
include an intelligent merging component that is smart about C and
can figure out which pieces of FSF code need to be overridden by
Apple code, even if the FSF code changed?  If not, then for *me*
it doesn't have any advantage over CVS, and there's no point in
trying to sell it to me.

Technology advocacy is like any other kind of selling; if the
customer doesn't buy, it's your failure, not the customer's.

Stan

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Bruce Stephens]

Stan Shebs <shebs@apple.com> writes:

[...]

> Now, almost all of *my* merge difficulties have been because Apple
> changes to GCC are logically contradictory to FSF code.  Does arch
> include an intelligent merging component that is smart about C and
> can figure out which pieces of FSF code need to be overridden by
> Apple code, even if the FSF code changed?

No, but (like other modern CM systems) it remembers what's been
merged.  So with CVS, you develop on a branch (presumably updating
with whats on the head), and when you want to update the head, CVS
does textual guessing to decide which apparent conflicts are real ones
(and this usually works pretty well, to be fair).  

Arch remembers the updates you've done on your branch, so when you
want to update the head, you'll get fewer spurious conflicts.  

So with arch, it makes sense to keep branches up to date with respect
to each other---it makes future merges easier.  With CVS, it's
sometimes the opposite.

(Arch knows about file renames and things, too, which would matter for
some projects, but possibly not gcc.)

> If not, then for *me* it doesn't have any advantage over CVS, and
> there's no point in trying to sell it to me.

Maybe not.  It's hard to say without looking in more detail and trying
experiments.

[...]

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Joseph S. Myers]

On Sun, 8 Dec 2002, Stan Shebs wrote:

> Now, almost all of *my* merge difficulties have been because Apple
> changes to GCC are logically contradictory to FSF code.  Does arch

Similarly, a common occurrence is that a new target, developed for some 
time in an external tree, is merged in, but it follows older coding 
standards and does not take account of global cleanups done to the main 
tree in the mean time.  How could arch tell that, say, FRV's xm-frv.h file 
ought to have been removed when xm-files.h were removed generally from the 
main tree, and the presence of such a file is a conflict, or that a 
particular target macro should have been removed (except that we use 
#pragma GCC poison to ensure that part), or that a certain coding style is 
obsolete, or that all occurrences of a spelling error had been fixed, or 
that something now needs documenting?

That sort of problem is what *I* generally see as merge problems - failure
to follow coding standards, especially as regards to documentation
(including comments), when patches are submitted, even though the issues
involved have been cleaned up in the tree before.  (And I include in this
small patches that didn't need a branch - if a patch is submitted that
includes some particular Texinfo error, when all such were previously
fixed, there's a logical conflict in that the new code would have been
fixed if it had been there previously.)  The basic mechanics of merging to
and from branches (a rare event, in any case) seem to work fine, the
logical aspects of keeping track of cleanups and refinements to coding
standards (involving in principle remembering on the order of a GB of mail
to the lists since the start of EGCS, though we try to include
documentation to reduce the effects of the impracticability of remembering
all the mail) need continual reminders to patch submitters to include
docs, or testcases, or that something in their patch is obsolete, or
misspelt, or will be ugly in the printed manual, or bad style.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: on reputation and lines and putting things places (Re: gccbranches?)

[Joel Sherrill]

"Joseph S. Myers" wrote:
> 
> On Sun, 8 Dec 2002, Stan Shebs wrote:
> 
> > Now, almost all of *my* merge difficulties have been because Apple
> > changes to GCC are logically contradictory to FSF code.  Does arch
> 
> Similarly, a common occurrence is that a new target, developed for some
> time in an external tree, is merged in, but it follows older coding
> standards and does not take account of global cleanups done to the main
> tree in the mean time.  How could arch tell that, say, FRV's xm-frv.h file
> ought to have been removed when xm-files.h were removed generally from the
> main tree, and the presence of such a file is a conflict, or that a
> particular target macro should have been removed (except that we use
> #pragma GCC poison to ensure that part), or that a certain coding style is
> obsolete, or that all occurrences of a spelling error had been fixed, or
> that something now needs documenting?
> 

If you find something that can really help on these issues, gcc is not
the
only project that has problems like this.  I have used CVS on
applications
that had small teams and still saw global fixes not accounted for when
someone merged their long checked out work.  All it takes is for someone
to
take a significant length of time to work on something while the rest of
the source base moves forward.  

I know that checking for problems like this in submissions to RTEMS is 
tedious and error prone.  I have ot know what version they worked with
and try to account for global changes that might be in the mix.

> --
> Joseph S. Myers
> jsm28@cam.ac.uk

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Tom Tromey]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

Joseph> That sort of problem is what *I* generally see as merge
Joseph> problems - failure to follow coding standards, especially as
Joseph> regards to documentation (including comments), when patches
Joseph> are submitted, even though the issues involved have been
Joseph> cleaned up in the tree before.

I agree.  But as you point out it's hard to keep up with all the
changes that go through.

In automake our approach has been to automate the checking of such
changes.  For instance, if we discover a new systemic error (sh and
make bugs occasionally pop up that require a sweep across all of
automake), we add a new entry to the `maintainer-check' target.  Then
you can run `make maintainer-check' to see if anything has regressed.
Maintainers are expected to keep the code maintainer-check-clean.

This is basically the same idea as poisoning identifiers in system.h.
As we've seen with warnings, if we can't automate it, there will be
regressions.

Tom

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Tom Lord]

       Now, almost all of *my* merge difficulties have been because
       Apple changes to GCC are logically contradictory to FSF code.
       Does arch include an intelligent merging component that is
       smart about C

Ok, I'm stumped, perhaps because I don't know the details of what you
are describing.  Why do you think a tool specifically knowledgable
about C is needed here?

If you have some fixed or slowly evolving deltas from FSF branches,
then arch can help you ... but that has nothing to do with C om
particular.

-t

Re: on reputation and lines and putting things places (Re: gcc branches?)

[Stan Shebs]

Tom Lord wrote:

>       Now, almost all of *my* merge difficulties have been because
>       Apple changes to GCC are logically contradictory to FSF code.
>       Does arch include an intelligent merging component that is
>       smart about C
>
>Ok, I'm stumped, perhaps because I don't know the details of what you
>are describing.  Why do you think a tool specifically knowledgable
>about C is needed here?
>
To take an example of something real-life, we have additional warning
flags not in FSF sources because of the collective spoon-gagging
response when they were suggested.  Now when Neil Booth reorganized
option flags into a c-opts.c (a good thing), I then had to go and
rewrite our local patches to fit this new scheme, deleting some code
(yay) and moving other bits into c-opts.c.  All of this was manual
work.

Sure, it's unreasonable to expect any CM system to somehow divine the
meaning of an arbitrary change, and then do an arbitrary rewrite of a
local patch to work with it, but that is what consumed the great
majority of my time when merging.  It may be more reasonable to
expect some class of patches to work - perhaps a local patch could be
made to follow the function it's patching, if the function is moved
to another file - but my real point is that at least for me, a change
of CM system would not have had much impact on the tasks that took
up the largest portion of my time.

Stan