* gcc branches? @ 2002-12-02 16:58 Per Bothner 2002-12-02 17:04 ` Zack Weinberg 0 siblings, 1 reply; 22+ messages in thread From: Per Bothner @ 2002-12-02 16:58 UTC (permalink / raw) To: gcc 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-02 16:58 gcc branches? Per Bothner @ 2002-12-02 17:04 ` Zack Weinberg 2002-12-02 17:09 ` Per Bothner 0 siblings, 1 reply; 22+ messages in thread From: Zack Weinberg @ 2002-12-02 17:04 UTC (permalink / raw) To: Per Bothner; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-02 17:04 ` Zack Weinberg @ 2002-12-02 17:09 ` Per Bothner 2002-12-02 17:32 ` Zack Weinberg 0 siblings, 1 reply; 22+ messages in thread From: Per Bothner @ 2002-12-02 17:09 UTC (permalink / raw) To: Zack Weinberg; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-02 17:09 ` Per Bothner @ 2002-12-02 17:32 ` Zack Weinberg 2002-12-02 18:03 ` Tom Lord 0 siblings, 1 reply; 22+ messages in thread From: Zack Weinberg @ 2002-12-02 17:32 UTC (permalink / raw) To: Per Bothner; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-02 17:32 ` Zack Weinberg @ 2002-12-02 18:03 ` Tom Lord 2002-12-06 14:43 ` Per Bothner 0 siblings, 1 reply; 22+ messages in thread From: Tom Lord @ 2002-12-02 18:03 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-02 18:03 ` Tom Lord @ 2002-12-06 14:43 ` Per Bothner 2002-12-07 2:40 ` Tom Lord 0 siblings, 1 reply; 22+ messages in thread From: Per Bothner @ 2002-12-06 14:43 UTC (permalink / raw) To: Tom Lord; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-06 14:43 ` Per Bothner @ 2002-12-07 2:40 ` Tom Lord 2002-12-07 3:11 ` Per Bothner 2002-12-07 15:41 ` Phil Edwards 0 siblings, 2 replies; 22+ messages in thread From: Tom Lord @ 2002-12-07 2:40 UTC (permalink / raw) To: per; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-07 2:40 ` Tom Lord @ 2002-12-07 3:11 ` Per Bothner 2002-12-07 2:34 ` Tom Lord 2002-12-07 15:41 ` Phil Edwards 1 sibling, 1 reply; 22+ messages in thread From: Per Bothner @ 2002-12-07 3:11 UTC (permalink / raw) To: Tom Lord; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-07 3:11 ` Per Bothner @ 2002-12-07 2:34 ` Tom Lord 2002-12-07 12:50 ` Per Bothner 0 siblings, 1 reply; 22+ messages in thread From: Tom Lord @ 2002-12-07 2:34 UTC (permalink / raw) To: per; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-07 2:34 ` Tom Lord @ 2002-12-07 12:50 ` Per Bothner 2002-12-07 13:06 ` Tom Lord 0 siblings, 1 reply; 22+ messages in thread From: Per Bothner @ 2002-12-07 12:50 UTC (permalink / raw) To: Tom Lord; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-07 12:50 ` Per Bothner @ 2002-12-07 13:06 ` Tom Lord 0 siblings, 0 replies; 22+ messages in thread From: Tom Lord @ 2002-12-07 13:06 UTC (permalink / raw) To: per; +Cc: gcc >> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: gcc branches? 2002-12-07 2:40 ` Tom Lord 2002-12-07 3:11 ` Per Bothner @ 2002-12-07 15:41 ` Phil Edwards 2002-12-07 17:18 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Lord 1 sibling, 1 reply; 22+ messages in thread From: Phil Edwards @ 2002-12-07 15:41 UTC (permalink / raw) To: Tom Lord; +Cc: per, gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* on reputation and lines and putting things places (Re: gcc branches?) 2002-12-07 15:41 ` Phil Edwards @ 2002-12-07 17:18 ` Tom Lord 2002-12-07 20:30 ` Tom Lord 2002-12-08 14:09 ` on reputation and lines and putting things places (Re: gcc branches?) Stan Shebs 0 siblings, 2 replies; 22+ messages in thread From: Tom Lord @ 2002-12-07 17:18 UTC (permalink / raw) To: phil; +Cc: per, gcc > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-07 17:18 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Lord @ 2002-12-07 20:30 ` Tom Lord 2002-12-08 10:23 ` on reputation and lines and putting things places (Re: gcc branche Kai Henningsen 2002-12-08 14:09 ` on reputation and lines and putting things places (Re: gcc branches?) Stan Shebs 1 sibling, 1 reply; 22+ messages in thread From: Tom Lord @ 2002-12-07 20:30 UTC (permalink / raw) To: gcc; +Cc: phil, per 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branche 2002-12-07 20:30 ` Tom Lord @ 2002-12-08 10:23 ` Kai Henningsen 0 siblings, 0 replies; 22+ messages in thread From: Kai Henningsen @ 2002-12-08 10:23 UTC (permalink / raw) To: lord; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-07 17:18 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Lord 2002-12-07 20:30 ` Tom Lord @ 2002-12-08 14:09 ` Stan Shebs 2002-12-08 14:45 ` Bruce Stephens ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Stan Shebs @ 2002-12-08 14:09 UTC (permalink / raw) To: Tom Lord; +Cc: phil, per, gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-08 14:09 ` on reputation and lines and putting things places (Re: gcc branches?) Stan Shebs @ 2002-12-08 14:45 ` Bruce Stephens 2002-12-08 16:24 ` Joseph S. Myers 2002-12-09 10:13 ` Tom Lord 2 siblings, 0 replies; 22+ messages in thread From: Bruce Stephens @ 2002-12-08 14:45 UTC (permalink / raw) To: gcc 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. [...] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-08 14:09 ` on reputation and lines and putting things places (Re: gcc branches?) Stan Shebs 2002-12-08 14:45 ` Bruce Stephens @ 2002-12-08 16:24 ` Joseph S. Myers 2002-12-08 16:49 ` on reputation and lines and putting things places (Re: gccbranches?) Joel Sherrill 2002-12-09 9:40 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Tromey 2002-12-09 10:13 ` Tom Lord 2 siblings, 2 replies; 22+ messages in thread From: Joseph S. Myers @ 2002-12-08 16:24 UTC (permalink / raw) To: Stan Shebs; +Cc: Tom Lord, gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gccbranches?) 2002-12-08 16:24 ` Joseph S. Myers @ 2002-12-08 16:49 ` Joel Sherrill 2002-12-09 9:40 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Tromey 1 sibling, 0 replies; 22+ messages in thread From: Joel Sherrill @ 2002-12-08 16:49 UTC (permalink / raw) To: Joseph S. Myers; +Cc: Stan Shebs, Tom Lord, gcc "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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-08 16:24 ` Joseph S. Myers 2002-12-08 16:49 ` on reputation and lines and putting things places (Re: gccbranches?) Joel Sherrill @ 2002-12-09 9:40 ` Tom Tromey 1 sibling, 0 replies; 22+ messages in thread From: Tom Tromey @ 2002-12-09 9:40 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc >>>>> "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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-08 14:09 ` on reputation and lines and putting things places (Re: gcc branches?) Stan Shebs 2002-12-08 14:45 ` Bruce Stephens 2002-12-08 16:24 ` Joseph S. Myers @ 2002-12-09 10:13 ` Tom Lord 2002-12-09 20:59 ` Stan Shebs 2 siblings, 1 reply; 22+ messages in thread From: Tom Lord @ 2002-12-09 10:13 UTC (permalink / raw) To: shebs; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: on reputation and lines and putting things places (Re: gcc branches?) 2002-12-09 10:13 ` Tom Lord @ 2002-12-09 20:59 ` Stan Shebs 0 siblings, 0 replies; 22+ messages in thread From: Stan Shebs @ 2002-12-09 20:59 UTC (permalink / raw) To: Tom Lord; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-12-10 3:16 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-02 16:58 gcc branches? Per Bothner 2002-12-02 17:04 ` Zack Weinberg 2002-12-02 17:09 ` Per Bothner 2002-12-02 17:32 ` Zack Weinberg 2002-12-02 18:03 ` Tom Lord 2002-12-06 14:43 ` Per Bothner 2002-12-07 2:40 ` Tom Lord 2002-12-07 3:11 ` Per Bothner 2002-12-07 2:34 ` Tom Lord 2002-12-07 12:50 ` Per Bothner 2002-12-07 13:06 ` Tom Lord 2002-12-07 15:41 ` Phil Edwards 2002-12-07 17:18 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Lord 2002-12-07 20:30 ` Tom Lord 2002-12-08 10:23 ` on reputation and lines and putting things places (Re: gcc branche Kai Henningsen 2002-12-08 14:09 ` on reputation and lines and putting things places (Re: gcc branches?) Stan Shebs 2002-12-08 14:45 ` Bruce Stephens 2002-12-08 16:24 ` Joseph S. Myers 2002-12-08 16:49 ` on reputation and lines and putting things places (Re: gccbranches?) Joel Sherrill 2002-12-09 9:40 ` on reputation and lines and putting things places (Re: gcc branches?) Tom Tromey 2002-12-09 10:13 ` Tom Lord 2002-12-09 20:59 ` Stan Shebs
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 read-only IMAP folder(s) and NNTP newsgroup(s).