Attachment 'rmqa-20100527.txt'

Download

   1 [2010-05-27 16:00:26] <mark> OK, it's 9:00 AM in California, so let's get started.
   2 [2010-05-27 16:00:40] <mark> Richi, Joseph (jsm28), and I are here.  Jakub can't join us today, unfortunately.
   3 [2010-05-27 16:00:57] <mark> With IRC, it's hard to avoid everyone talking at once and it's hard to know when people are done talking.
   4 [2010-05-27 16:01:11] <mark> So, let's try to ask one question at a time, and then let's say "DONE" when we're done.
   5 [2010-05-27 16:01:24] <mark> Who wants to lead off with a question?
   6 [2010-05-27 16:01:31] <mark> If nobody speaks up, we'll take some off the Wiki page.
   7 [2010-05-27 16:01:42] =-= richi has changed the topic to ``RM Q&A''
   8 [2010-05-27 16:02:11] <mark> Deafening silence.  OK, let's start with this one:
   9 [2010-05-27 16:02:18] <mark> What would be your response to a proposal for more frequent releases (every 6 months, say) with at most 2 major changes merged from reasonably-stable development branches (i.e. stricter merge criteria)? 
  10 [2010-05-27 16:02:24] <mark> richi, jsm28: Do you want to answer?
  11 [2010-05-27 16:02:34] <jsm28> I don't believe we are currently effective at stabilizing trunk quickly enough for such a six-month cycle to work.
  12 [2010-05-27 16:02:35] <richi> I'll try to answer
  13 [2010-05-27 16:02:40] <richi> agreed
  14 [2010-05-27 16:02:47] * mark too
  15 [2010-05-27 16:02:53] <jsm28> Also, I think too much emphasis is being given here and in the written plan to branches - to how something is developed rather than how stable or risky it is.  We should be assessing stability and risk rather than trying to work out what is or is not a "major change", or whether a sequence of large but incremental changes towards a particular goal counts as one change or more than one.
  16 [2010-05-27 16:02:58] <stevenb> that question is mine, btw
  17 [2010-05-27 16:03:05] <jsm28> DONE.
  18 [2010-05-27 16:03:17] <mark> OK, what about this follow-on question:
  19 [2010-05-27 16:03:23] <mark> What would be your response to a proposal for a development plan where to be merged branches *must* be in good enough shape for merging in stage 1 (i.e. meet merge criteria) before stage 3 of the *active* release cycle begins?
  20 [2010-05-27 16:03:48] <jsm28> Again, I think this has too much emphasis on how something is developed.  If something is ready it doesn't matter whether it too two weeks or two years to develop.  If it's been around a long time, if anything it's likely to need *more* work to make it merge-ready because of needing updates for global cleanups that have been made in GCC since it branched off.
  21 [2010-05-27 16:03:56] <jsm28> DONE.  Anyone else want to comment?
  22 [2010-05-27 16:03:59] <stevenb> yes
  23 [2010-05-27 16:04:03] <richi> that's putting developers off which we want to attract instead.  Less rules please.
  24 [2010-05-27 16:04:11] <mark> stevenb: OK, go ahead.
  25 [2010-05-27 16:04:17] <stevenb> the point is that too much work ends up done in stage1 that should have been ready before the merge
  26 [2010-05-27 16:04:31] <stevenb> very few of the latest big branch merges were ready
  27 [2010-05-27 16:04:41] <stevenb> and that is one of the reasons why the 6 month cycle doesn't work
  28 [2010-05-27 16:04:49] <jsm28> That sounds like we aren't assessing stability/risk well enough.
  29 [2010-05-27 16:04:54] <mark> stevenb: I think I'd like to see branches more ready before merging -- but not necessary before stage 1.
  30 [2010-05-27 16:05:11] <jsm28> If we can define what makes a patch ready, we don't need a rule about it being ready N months beforehand.
  31 [2010-05-27 16:05:20] <mark> I think the problem is that we're pulling branches in before they're mature.
  32 [2010-05-27 16:05:21] <stevenb> that's also good
  33 [2010-05-27 16:05:22] <richi> stevenb: there is also the risk that nobody fixes bugs during stage3/4 but instead makes branches ready for stage1
  34 [2010-05-27 16:05:24] <mark> DONE.
  35 [2010-05-27 16:05:34] <stevenb> richi: that is why i said: before stage 3
  36 [2010-05-27 16:05:59] <mark> OK, let's maybe ask this perennial favorite from the Wiki page:
  37 [2010-05-27 16:06:05] <richi> stevenb: I think that would only be reasonabvle with a much shorter release cycle
  38 [2010-05-27 16:06:06] <mark> Do you agree it is necessary, based on experience of the latest few releases, to involve more developers in bug fixing in stage 3 to reduce release cycle lengths? If so, do you have ideas about how to do this? 
  39 [2010-05-27 16:06:19] <mark> I will try to answer that.
  40 [2010-05-27 16:06:25] <stevenb> richi: yes, and i asked for that too ;) but it's marked done, so next
  41 [2010-05-27 16:06:47] <mark> First, I'm not sure that approximately annual releases are too infrequent.  In other words, I'm not sure a shorter cycle would be better.  It feels OK to me.
  42 [2010-05-27 16:06:59] <mark> People don't want to update their compilers that often; many people wish they changed less frequently!
  43 [2010-05-27 16:07:08] <mark> But, I sure wish we had more bug-fixers.
  44 [2010-05-27 16:07:14] <mark> Unfortunately, I don't know how to drive that.
  45 [2010-05-27 16:07:24] <mark> I've worried about that for a decade without a good answer.
  46 [2010-05-27 16:07:28] <mark> DONE.
  47 [2010-05-27 16:07:31] <mark> jsm28, richi: ?
  48 [2010-05-27 16:07:35] <jsm28> I think having more people working on bug fixing would help, yes, and that the bug fixing stages are the ones that could most usefully be shortened.  I do not have ideas on how to motivate this.
  49 [2010-05-27 16:07:38] <jsm28> DONE.
  50 [2010-05-27 16:07:43] <stevenb> mark: you have to look at where developers go in stage3 (branches), and try to avoid they go there
  51 [2010-05-27 16:07:45] <richi> I have no idea either.  DONE.
  52 [2010-05-27 16:08:04] <mark> stevenb: Do you have a suggestion as to how to do that?
  53 [2010-05-27 16:08:05] <stevenb> mark: the whole set of the above three questions is basically one big proposal
  54 [2010-05-27 16:08:31] <mark> stevenb: OK, let me try to summarize what I think you're suggesting.
  55 [2010-05-27 16:08:37] <stevenb> mark: if you require that a branch is sufficiently stable (for some measure of...) before stage 3, then folks don't have to work on that anymore in stage 3
  56 [2010-05-27 16:08:47] <stevenb> mark: with shorter release cycle, it never takes long for a branch to merge
  57 [2010-05-27 16:08:48] <jsm28> I'd rather represent any change positively (people bug fix *as well as* what they do now) rather than trying to replace A with B.
  58 [2010-05-27 16:08:58] <mark> I think you're saying that if people have to do their big branches early, then they won't be distracted later.
  59 [2010-05-27 16:09:11] <stevenb> mark: so that developers on a branch effectively still have ~1 year between start of work and seeing it in a released gcc
  60 [2010-05-27 16:09:15] <stevenb> yes
  61 [2010-05-27 16:09:35] <richi> stevenb: we already have eliminated the odd stage2 (unfortunatley with enlarging stage1 from 2 to effectively 6 month)
  62 [2010-05-27 16:09:46] <mark> But, I think that means that people will be trying to work on 4.7 branches when we're trying to get 4.5 stabilized, instead of working on 4.6 branches when we're trying to get 4.7 stabilized.
  63 [2010-05-27 16:09:54] <stevenb> richi: that's just a different label on the same basic process
  64 [2010-05-27 16:09:56] <mark> DONE.
  65 [2010-05-27 16:10:17] <mark> Here's something non-controversial: 
  66 [2010-05-27 16:10:19] <mark> Could we name differently the stages (e.g. red, orange, green, or major, minor, fixing, or anything else...) since having numbered stages 1, 2, 4 without the 3 is very confusing. 
  67 [2010-05-27 16:10:20] <richi> The fundamental issue is also that more frequent major releases will not get enough testing.  DONE
  68 [2010-05-27 16:10:39] <mark> I think we can all agree that 1,2, 4 is a weird numbering system.
  69 [2010-05-27 16:10:40] <jsm28> Actually they are 1, 3, 4 rather than 1, 2, 4.  And I think red, orange, green would be even less meaningful.  You could name them New Features, Bug Fixing, Regression Only or similar.  DONE.
  70 [2010-05-27 16:10:43] <mark> The next stage would be 8. :-)
  71 [2010-05-27 16:11:01] <mark> I think New Features, Bug Fixing, Regressions Only is a good call.  DONE.
  72 [2010-05-27 16:11:13] <stevenb> stage "New Features" :)
  73 [2010-05-27 16:11:14] <richi> Agreed.  DONE.
  74 [2010-05-27 16:11:27] <mark> Woohoo, progress! :-)
  75 [2010-05-27 16:11:34] <matz> But it's not just features in stage 1.  It's also other disruptive changes.
  76 [2010-05-27 16:11:35] <mark> All right, any questions from the floor?
  77 [2010-05-27 16:11:38] <richi> I wanted to avoid re-using "stage 2" as it has a defined meaning to some people
  78 [2010-05-27 16:11:43] <matz> So why not "Everything goes" :)
  79 [2010-05-27 16:11:51] <stevenb> mark: will someone add these answers or a summary to the wiki?
  80 [2010-05-27 16:11:57] <mark> matz: OK by me. :-)
  81 [2010-05-27 16:11:59] <richi> "Development" "Bugfixing".  Reduce it to two stages then.
  82 [2010-05-27 16:12:07] <mark> stevenb: jsm28 is logging this chat, and will post it on the Wiki.
  83 [2010-05-27 16:12:10] <stevenb> ok
  84 [2010-05-27 16:12:10] <jsm28> The numbers are also used for bootstrap stages, though that doesn't seem to cause confusion in practice.
  85 [2010-05-27 16:12:44] <mark> OK, I have a question.
  86 [2010-05-27 16:13:13] <mark> How important is absolute libstdc++ ABI compatibility over time?  I took the position recently that I thought it was critical, just like for GLIBC.  But, what do other people think?
  87 [2010-05-27 16:13:44] <sabre> Doesn't that depend on the distributors involved?
  88 [2010-05-27 16:13:50] <jsm28> I think we can change the soname, but not break compatibility with old binaries unless we change the soname.
  89 [2010-05-27 16:14:10] <jsm28> I think changing the soname is a matter for the libstdc++ maintainers.  I would ask that when they decide to move to libstdc++.so.7 they try to make sure that no further incompatible changes will be needed for a complete C++0x implementation.
  90 [2010-05-27 16:14:26] <jsm28> Furthermore, when we move to libstdc++.so.7 we should take the opportunity to change the default -fabi-version for the C++ compiler to include all the ABI bug-fixes that have accumulated since the last ABI break.  Again, we should try to make sure that no more incompatible changes will be needed to the language ABI for a complete C++0x implementation.
  91 [2010-05-27 16:14:27] <jsm28> DONE.
  92 [2010-05-27 16:14:42] <mark> sabre: I think it's a question for us as GCC RMs; the distributors will have a hard time compensating if we make ABI changes.
  93 [2010-05-27 16:14:50] <mark> jsm28: I think what you say makes a lot of sense.  DONE.
  94 [2010-05-27 16:14:58] <stevenb> can you use STOP instead of DONE please? makes this look more like good old telegrams
  95 [2010-05-27 16:15:11] <mark> :-)
  96 [2010-05-27 16:15:18] <sabre> so question for the gcc RMs: how best to coordinate gcc changes like that with releases of various linux (and other unix) distros?
  97 [2010-05-27 16:15:32] <matz> libstdc++ ABI breakage is fairly terrible for distributors.
  98 [2010-05-27 16:15:42] <mark> richi: You're a C++ guy in an alternate life -- any thoughts?
  99 [2010-05-27 16:15:59] <mark> (And a SuSE guy so perhaps you can answer sabre's question?)
 100 [2010-05-27 16:16:02] <matz> The largest point here is plugin capable systems having c++ plugins (mozilla + flash)
 101 [2010-05-27 16:16:04] <richi> sabre: the vendors will fix all gcc bugs in time
 102 [2010-05-27 16:16:14] <richi> mark: I prefer a stable libstdc++ ABI
 103 [2010-05-27 16:16:38] <stevenb> fwiw the new Airbus structure tools use gcc for its libstdc++ stabiliy, even on proprietary unix variants
 104 [2010-05-27 16:16:48] <stevenb> so it matters
 105 [2010-05-27 16:16:53] <stevenb> to some
 106 [2010-05-27 16:16:55] <jsm28> The soname has been fixed for a long time now.
 107 [2010-05-27 16:17:15] <matz> jsm28: Yes, sorry to be unclear, I was talking about the soname.
 108 [2010-05-27 16:17:31] <matz> Forward compatible changes are easy to deal with.
 109 [2010-05-27 16:17:48] <mark> richi: Are you able to say whether SuSE/Red Hat/Debian/Ubuntu/etc. have any formal coordination re. GCC releases?
 110 [2010-05-27 16:17:49] <jsm28> Certainly 3.4 used the same soname.
 111 [2010-05-27 16:18:04] <mark> jsm28: Sorry, didn't mean to cut you off.
 112 [2010-05-27 16:18:19] <richi> mark: no, we just pick what's ready.  If it's not ready we have to maek it ready or backport HW enablement changes.
 113 [2010-05-27 16:18:30] <matz> jsm28: I fear I don't get what you're trying to say.
 114 [2010-05-27 16:19:03] <jsm28> matz: Just observing that it has indeed been stable for a long time - if we change it now, that's not as if we change it every year.
 115 [2010-05-27 16:19:20] <matz> Oh agreed.  But even a change every 10 years is terrible.
 116 [2010-05-27 16:19:23] <richi> jsm28: libstdc++.so.5 is still used ...
 117 [2010-05-27 16:19:25] <tromey> I still occasionally hear complaints about the bad old days when libstdc++ changed a lot.  People hated this.  So if we do change it I think the messaging is important
 118 [2010-05-27 16:19:47] <mark> jsm28: The soname has been stable.   Has the libstdc++ ABI been stable since GCC 3.4?  Or has the ABI shifted without the soname shifting?
 119 [2010-05-27 16:20:02] <dgregor> C++0x is a great excuse to change the libstdc++ ABI moving forward
 120 [2010-05-27 16:20:05] <jsm28> mark: I don't know.
 121 [2010-05-27 16:20:20] * mark neither
 122 [2010-05-27 16:20:21] <tromey> Jakub would know the answer to that.  I think there were some obscure changes
 123 [2010-05-27 16:20:34] <mark> OK.
 124 [2010-05-27 16:20:37] <matz> I think so too.
 125 [2010-05-27 16:20:42] * jsm28 remembers the libc5-to-libc6 transition, but Linux was much less widely used then
 126 [2010-05-27 16:20:54] <mark> OK, speaking of C++:
 127 [2010-05-27 16:21:03] <mark> In your opinion, should GCC complete the transition to C++ as the main implementation language? 
 128 [2010-05-27 16:21:06] <mark> <from the Wiki>
 129 [2010-05-27 16:21:12] <mark> jsm28, richi: Any thoughts?
 130 [2010-05-27 16:21:16] <richi> yes.  STOP.
 131 [2010-05-27 16:21:23] <dnovillo> yes!  STOP
 132 [2010-05-27 16:21:26] <matz> But in fact to some it's better to live with obscure bugs (for not changing soname when strictly required), rather than to live with a soname change to fix those obscure bugs.
 133 [2010-05-27 16:21:32] <richi> but it's a maintainers call, not RMs IMHO
 134 [2010-05-27 16:21:39] <TobFZJ> stevenb/RMs/all: What is about libgfortran stability. (There is a difficult-to-avoid ABI [stable since 4.3] break planned for a new array descriptor [required for some bug fixes and some F2003 features]) STOP
 135 [2010-05-27 16:21:41] <jsm28> I think the C++ transition would be appropriate to replace the various places C++ features are emulated in C (mainly using macros), such as vec.h.  I don't think a wholesale coding style change, as opposed to using standard features to replace local macros, would be a productive use of time.
 136 [2010-05-27 16:21:47] <jsm28> The transition needs someone to drive it forward, producing patches that demonstrate the benefits of using C++ so there is something concrete for the SC to review.  (I don't think this is anything to do with the FSF, just the SC.)  STOP.
 137 [2010-05-27 16:22:26] <mark> jsm28: I agree with the thought that we don't need to turn the whole sourcebase upside down.  But, I'd be in favor of switching to being able to use C++ features and libraries as appropriate.
 138 [2010-05-27 16:22:26] <dnovillo> IMO, with the modular gcc effort we could move that question to the resulting libraries.  STOP
 139 [2010-05-27 16:22:28] <stevenb> jsm28: let's take a practical example,
 140 [2010-05-27 16:22:33] <matz> And I'd like it very much if those patches introducing C++ prove that they don't affect performance in either way.  Not for developing GCC itself, nor for developing with GCC.
 141 [2010-05-27 16:22:48] <stevenb> jsm28: the 'tree' data structure. i'd like to hide it. say gcc would go c++. what changes would be acceptable?
 142 [2010-05-27 16:22:51] <jsm28> TobFZJ: As with libstdc++, I'd leave that to the relevant maintainers.  There are fewer users, so more freedom to make such changes.
 143 [2010-05-27 16:22:59] <matz> Or wait, I'm fine if they improve performance, so make that "to the worse" :)
 144 [2010-05-27 16:23:01] <mark> jsm28: Furthermore, I think this is someone that might need SC blessing, but I think we should ignore the FSF question.
 145 [2010-05-27 16:23:05] <stevenb> jsm28: hide it in a name space? hide the data structure behind accessor functions/
 146 [2010-05-27 16:23:07] <stevenb> ?
 147 [2010-05-27 16:23:21] <mark> In other words, the fact that RMS doesn't want us to use C++ doesn't carry any water with me.
 148 [2010-05-27 16:23:33] <mark> I'd ask the SC for permission, and if that came back positive, go ahead.
 149 [2010-05-27 16:23:34] <mark> STOP.
 150 [2010-05-27 16:23:41] <jsm28> stevenb: Replace macros by accessors, probably.  Replace unions for the different sorts of trees, likewise.  STOP
 151 [2010-05-27 16:23:55] <dnovillo> mark: why ask a technical decision to the SC?
 152 [2010-05-27 16:23:57] <dnovillo> STOP
 153 [2010-05-27 16:24:00] <stevenb> i keep forgetting the stop. STOP.
 154 [2010-05-27 16:24:22] <richi> dnovillo: because of the C++ host compiler requirement only.  STOP
 155 [2010-05-27 16:24:32] <mark> dnovillo: Fair question.  It seems overarching enough that it seems appropriate.  STOP.
 156 [2010-05-27 16:24:53] <richi> dnovillo: the technical side should be the maintainers calls only.
 157 [2010-05-27 16:25:01] <jsm28> I think the SC gets to deal with controversial technical questions.  If it's not controversial, no need to bring in the SC.  STOP.
 158 [2010-05-27 16:25:02] <stevenb> TobFZJ: re. libfortran, i think abi is less important. people tend to compile their own code, there are no real large apps commercially distributed
 159 [2010-05-27 16:25:42] <mark> stevenb: There are some big libraries, though.  I'd be worried if ATLAS ABIs were changing.
 160 [2010-05-27 16:26:00] <mark> richi, dnovillo: I don't quite understand richi's last comment.
 161 [2010-05-27 16:26:12] <mark> Richi, I agree -- most technical issues shouldn't require the SC at all.
 162 [2010-05-27 16:26:15] <mark> Was that what you were saying?
 163 [2010-05-27 16:26:31] <richi> mark: I don't want to ask the SC about switching to C++.  I want to ask them if it's ok to require a C++ host compiler though.
 164 [2010-05-27 16:26:50] <jsm28> If we do move to move C++-style datastructures, can someone produce a quick guide to whatever bits of the ABI are needed to tell if those structures are larger than they would be in C?  I know how to tell how large a "tree" is, but not what hidden data a C++ structure might have or whether a patch is making it larger.  STOP.
 165 [2010-05-27 16:27:20] <mark> richi: Oh, I see.  Because that has an impact on "users" (where here we mean people who build and install GCC themselves)?  STOP.
 166 [2010-05-27 16:27:32] <mark> (that = "require C++ host compiler")
 167 [2010-05-27 16:27:33] <richi> mark: yes, exactly
 168 [2010-05-27 16:27:48] <mark> richi: OK.
 169 [2010-05-27 16:28:11] <mark> OK, well, hey, I can ask the SC.
 170 [2010-05-27 16:28:14] <richi> jsm28: I think you can inspect dwarf
 171 [2010-05-27 16:28:22] <mark> Anybody here want to pop up and say stop?
 172 [2010-05-27 16:28:25] <stevenb> to add to jsm28's question about ABI/size: also code style guides before anyone starts actually using c++. STOP
 173 [2010-05-27 16:28:28] <mark> (re. asking SC about C++)?
 174 [2010-05-27 16:28:32] <richi> jsm28: I am mostly looking forward to stl use, namespaces and function overloading
 175 [2010-05-27 16:28:57] <richi> in increasing order of importance ;)
 176 [2010-05-27 16:28:57] <matz> STL use will slow down compilation of GCC pretty much.
 177 [2010-05-27 16:29:00] <jsm28> richi: I'm hoping for something easier to do in patch review to tell if there's hidden overhead in a patch.  I rarely compile with a patch when reviewing it.  STOP.
 178 [2010-05-27 16:29:31] <jsm28> richi: Where would function overloading be useful in GCC?
 179 [2010-05-27 16:29:39] <richi> jsm28: we could regression test certain sizes
 180 [2010-05-27 16:29:40] <mark> OK, I think we can all agree that we need C++ coding standards and that we want to transition to "fancy stuff" (e.g., virtual functions, inheritance, multilpe inheritance) slowly.  STOP.
 181 [2010-05-27 16:29:51] <stevenb> or not at all STOP
 182 [2010-05-27 16:29:59] <stevenb> (esp. multiple inheritance)
 183 [2010-05-27 16:30:04] <mark> Yes, possibly with infinite slowness. :-)
 184 [2010-05-27 16:30:10] <matz> And we need such coding standards before people go wild in producing "cleanup" patches.
 185 [2010-05-27 16:30:13] <richi> jsm28: different arguments to int_plus, double_ints, ints, trees, etc. w/o all different fancy names
 186 [2010-05-27 16:30:26] <jsm28> vec.h is near the top of the list of things to switch to C++.
 187 [2010-05-27 16:30:43] <stevenb> so is basic-block.h
 188 [2010-05-27 16:30:46] <richi> mark: like that std::sort one? ;)
 189 [2010-05-27 16:30:57] <mark> :-)
 190 [2010-05-27 16:31:08] <richi> matz I meant - stupid autocompletion
 191 [2010-05-27 16:31:29] <mark> OK, anyone else want to ask a question from the floor?
 192 [2010-05-27 16:31:31] <matz> like that one, yes.
 193 [2010-05-27 16:31:32] <jsm28> qsort at least people know as standard C so replacing it is less important than replacing vec.h which is GCC-specific.
 194 [2010-05-27 16:31:55] <richi> indeed.
 195 [2010-05-27 16:32:01] <mark> To close out the previous one, I think I'll go ahead and ask the SC about the C++ host compiler.  Or do people think I should post on gcc@gcc.gnu.org before doing that?
 196 [2010-05-27 16:32:12] <stevenb> mark: yes. can we assign actions to people here too? or it'll probably go nowhere from here anytime soon... stop
 197 [2010-05-27 16:32:31] <mark> stevenb: Yes, I should ask the SC, or yes, I should ask on the mailing list?  STOP.
 198 [2010-05-27 16:32:54] <stevenb> mark: yes, questions from the floor. 
 199 [2010-05-27 16:32:55] <jsm28> It's not just "is it OK to require such a compiler?" but what requirements should be placed on it.  GCC 4.1 or later?  Require code also to be C++98 (except for long long) so it can work with other compilers?  STOP.
 200 [2010-05-27 16:33:02] <stevenb> mark: you're way ahead of me. STOP
 201 [2010-05-27 16:33:17] <mark> stevenb: -)
 202 [2010-05-27 16:33:30] <richi> jsm28: require strict C++98
 203 [2010-05-27 16:33:32] <mark> jsm28: Yes, I think C++98 is the only practical choice, and, yes, we should say that.
 204 [2010-05-27 16:33:45] <mark> stevenb: Let's finish this up, and then I'll take your question.
 205 [2010-05-27 16:33:54] <jsm28> richi: Plus long long, as I said.  GCC requires a 64-bit type.  STOP.
 206 [2010-05-27 16:34:13] * mark is trying to figure out if it will be considered inconsiderate if I take this to the SC without another round of mailing list discussion.
 207 [2010-05-27 16:34:41] <richi> mark: the SC outcome shouldn't be the result of the question whether we want to switch
 208 [2010-05-27 16:34:54] <matz> mark: Well, you can ask the SC without discussion.  Then at least that part is solved when the discussion starts.
 209 [2010-05-27 16:35:01] <mark> OK, fair enough.
 210 [2010-05-27 16:35:06] * mark takes that action item, then
 211 [2010-05-27 16:35:22] <tromey> woo hoo STOP
 212 [2010-05-27 16:35:26] <jsm28> The SC question should be whether the requirement would be OK, given a patch that gives enough reason to switch.  STOP.
 213 [2010-05-27 16:35:35] <mark> stevenb: OK, go ahead.
 214 [2010-05-27 16:37:03] <stevenb> mark: eh
 215 [2010-05-27 16:37:07] <stevenb> mark: yes. can we assign actions to people here too? or it'll probably go nowhere from here anytime soon... stop
 216 [2010-05-27 16:37:18] <stevenb> mark: but you were already doing that
 217 [2010-05-27 16:37:25] <stevenb> mark: anyway, i do have another question
 218 [2010-05-27 16:37:31] <mark> OK, go for  it.
 219 [2010-05-27 16:37:58] <stevenb> mark: re. technical leadership, it seems to me that there are some issues where gcc the community just doesn't move forward because thigns are controversial
 220 [2010-05-27 16:38:07] <stevenb> mark: see e.g. splitting up the gcc/ directory
 221 [2010-05-27 16:38:22] <jsm28> stevenb: I don't see that as controversial, but carry on with the question.
 222 [2010-05-27 16:38:33] <stevenb> mark: i think that you as RMs and highly respected technical folks should the lead in this, show technical leadership
 223 [2010-05-27 16:38:39] <richi> stevenb: we do not have technical leadership
 224 [2010-05-27 16:38:41] <stevenb> mark: do you agree
 225 [2010-05-27 16:38:49] <mark> stevenb: Great question.
 226 [2010-05-27 16:38:49] <stevenb> richi: i'm arguing you should have it
 227 [2010-05-27 16:39:02] <mark> I have a bit of a long answer.
 228 [2010-05-27 16:39:04] <mark> Bear with me.
 229 [2010-05-27 16:39:17] <stevenb> richi: there are 3, 4 folks from different background with lot of respect in the community. i think it would be accepted. stop
 230 [2010-05-27 16:39:24] <mark> I do think we as RMs should lead more.  I feel that we've been too passive over the past couple of cycles.
 231 [2010-05-27 16:39:35] <mark> I think we can't *make* things happen, but we can try to set direction.
 232 [2010-05-27 16:39:45] <mark> We can try to encourage people with spare cycles to run <this way> rather than <that way>.
 233 [2010-05-27 16:39:50] <mark> And we can cheerlead.
 234 [2010-05-27 16:40:08] <mark> That's part of why I'm trying to re-involve myself more in the day-to-day of GCC.  I won't be doing ay coding of consequence, but I'm hoping I can help lead.
 235 [2010-05-27 16:40:25] <mark> However, I think that jsm28 and richi disagree with me, based on some of our calls.
 236 [2010-05-27 16:40:33] <mark> So, I want to let them speak up.
 237 [2010-05-27 16:40:40] <mark> js82, richi: ?
 238 [2010-05-27 16:40:42] <mark> stop
 239 [2010-05-27 16:40:58] <richi> mark: that's a good suggestion though I already see this happening with directed reviews.  It of course doesn't help when people come up with complete implementations that go in the wrong direction (hello google).  STOP.
 240 [2010-05-27 16:41:06] <iant> I think gcc has not had an overall architect since RTH dropped out
 241 [2010-05-27 16:41:12] <iant> I think that has been a problem
 242 [2010-05-27 16:41:18] <iant> There is no one person who can say "yes" or "no"
 243 [2010-05-27 16:41:26] <iant> STOP
 244 [2010-05-27 16:41:54] <richi> mark: I also have the "problem" myself.  The last couple of RFCs for infrastructure changes received _zero_ comments.
 245 [2010-05-27 16:41:57] <jsm28> I'm wary of saying "people should do X" except in the context of "I'm contributing this patch that does X(a), X(b) and X(c) and I think it would be great if someone added X(d) and X(e) to it.".
 246 [2010-05-27 16:42:06] <iant> The Google issue is a separate one (and the fault is not only Google's, it requires work on both sides) STOP
 247 [2010-05-27 16:42:27] <mark> Let's not get into Google/Apple/Microsoft/Red Hat/CodeSourcery here.
 248 [2010-05-27 16:42:35] <mark> Probably a good discussion, but not this one.
 249 [2010-05-27 16:42:36] <jsm28> That is, my instinct is leadership through code rather than talk, which takes time coding.
 250 [2010-05-27 16:43:04] <richi> jsm28: I agree.  Talk is cheap
 251 [2010-05-27 16:43:08] <iant> jsm28: agreed but I think it helps a great deal if someone can say "yes" or "no"
 252 [2010-05-27 16:43:23] <matz> iant: The maintainers can.
 253 [2010-05-27 16:43:26] <richi> iant: I mostly see nobody saying anything
 254 [2010-05-27 16:43:32] <jsm28> But if people think RMs should post visions for where GCC should go in the next five years say, I suppose we could do that.  STOP.
 255 [2010-05-27 16:43:35] <stevenb> i think there are people (hi!) who just won't post code because there is close to zero chance of it getting anywhere
 256 [2010-05-27 16:43:39] <iant> matz: sure, but they don't; richi: right, that's the problem
 257 [2010-05-27 16:43:58] <richi> iant: nobody complained about DECL_PT_UID for example, or enlarging all call stmts by two points-to sets
 258 [2010-05-27 16:44:10] <iant> I'm not being clear; it's not that nobody has the power, it's that nobody takes that role
 259 [2010-05-27 16:44:14] <mark> jsm28: Indeed, and you're an exceptional engineer.  I'm probably compensating for my lack of engineering by hoping there's value elsewhere.  But, I'm willing to be a yes/no resource, at least for big-picture strategy things.
 260 [2010-05-27 16:44:14] <stevenb> richi: they were the right thing to do
 261 [2010-05-27 16:44:22] <matz> iant: That's a general problem of not having very many reviewers.  The non-existance of overall guidance just follows from that.
 262 [2010-05-27 16:44:23] <stevenb> richi: there is usually just not much wrong with your calls
 263 [2010-05-27 16:44:32] <richi> stevenb: yes, but even saying "yes" would be helpful sometimes
 264 [2010-05-27 16:44:44] <stevenb> i'll remember that
 265 [2010-05-27 16:44:57] <iant> matz: I'm looking at the problem at a slightly higher level, but perhaps it is just a maintainer issue
 266 [2010-05-27 16:45:02] <mark> iant: You're very knowledgeable about GCC -- do you think you could be more RTH-like on technical things?
 267 [2010-05-27 16:45:15] <mark> Or are you too busy?  Or not confident in making those calls?
 268 [2010-05-27 16:45:24] <tromey> I thought the SC stopped giving people RTH-like power STOP
 269 [2010-05-27 16:45:32] <mark> It did.
 270 [2010-05-27 16:45:46] <jsm28> tromey: We still have Global Reviewers, and were talking about review....
 271 [2010-05-27 16:45:47] <iant> I could perhaps do the job but I am too busy working on other things
 272 [2010-05-27 16:45:58] <iant> there are other people who could do the job too
 273 [2010-05-27 16:46:06] <mark> iant: OK.
 274 [2010-05-27 16:46:10] <iant> the RTH power that was taken away was the power to commit anything
 275 [2010-05-27 16:46:22] <stevenb> mark: note, my question is not so much about individuals giving direction, but just saying, "OK, everyone has had their say. Here's how we're going to proceed."
 276 [2010-05-27 16:46:33] <iant> yes
 277 [2010-05-27 16:46:37] <stevenb> mark: because too often discussions just die out with no action
 278 [2010-05-27 16:46:56] <richi> stevenb: isn't this just because it just was talk and nobody wanted to do the work?
 279 [2010-05-27 16:47:01] <jsm28> stevenb: You mean global discussions?  Because for local ones I'd think that's for the relevant maintainer.
 280 [2010-05-27 16:47:22] <matz> richi: Right.
 281 [2010-05-27 16:47:25] <stevenb> jsm28: global ones, yes. the split-up of gcc/ is at the moment the most relevant one and the best example
 282 [2010-05-27 16:47:32] <mark> stevenb: I understand.  In corporate terms, we're lacking a CEO.  We have a board of directors (the SC), but not really someone who can say "OK, I've heard the input -- here's what we're doing."  Now, the question is whether we *want* a CEO.  Maybe we feel that's concentrating too much power in one place.
 283 [2010-05-27 16:47:48] <richi> I have many great ideas but not enough time to implement them all myself.  And I don't think talking about them would help much.
 284 [2010-05-27 16:47:50] <matz> It doesn't help the slightest bit if someone empowered enough says "and that's the way", if then nobody follows that way.
 285 [2010-05-27 16:48:06] <stevenb> mark: i would say that the power has naturally distributed itself fairly well with this group hug approach to RM
 286 [2010-05-27 16:48:38] * mark is certainly happy that he asked the SC for permission to expand  RM-ness to Jakub, Joseph, and Richard.
 287 [2010-05-27 16:48:56] <stevenb> mark: also the number of issues where it really matters mostly concern the architecture of the compiler as a whole, the direction. there are not that many issues of this kind. stop
 288 [2010-05-27 16:48:59] <iant> mark: I think our policies prevent too much concentration of power
 289 [2010-05-27 16:48:59] <jsm28> stevenb: I still don't think that's controversial.  Is there actually a bikeshed where one person wants a directory "gimple" and another wants "libgimple" and another wants a toplevel directory and no-one will just review a patch to create it with one name?
 290 [2010-05-27 16:49:26] <richi> stevenb: simply start with separating out the C frontend.  finally.
 291 [2010-05-27 16:49:30] <stevenb> jsm28: i also don't think it's controversial, but the bikeshed discussion is what i would like to end with a decision
 292 [2010-05-27 16:49:40] <richi> stevenb: I don't like gimple/, rtl/ and all the fluff diego proposed though
 293 [2010-05-27 16:49:47] <stevenb> richi: i have to talk to jsm28 about that, there's something with c-common but i don't remember
 294 [2010-05-27 16:49:50] <jsm28> richi, stevenb: I've previously posted what I think the names should be for C front-end subdirectories.
 295 [2010-05-27 16:50:02] <stevenb> richi: but it's obviously in the line of things i've tried to achieve lately
 296 [2010-05-27 16:50:11] <matz> stevenb: I think, ultimately the way to stop bikeshedding is to create a patch for review.
 297 [2010-05-27 16:50:12] <richi> stevenb: yep - very much appreciated.
 298 [2010-05-27 16:50:13] <mark> OK, let's not get into a specific technical topic.
 299 [2010-05-27 16:50:18] <stevenb> jsm28: yes you have, but i can't find it anymore! :(
 300 [2010-05-27 16:50:44] <jsm28> "Re: Separate dir for the C frontend", gcc list, 12 Sep 2004, for example.
 301 [2010-05-27 16:50:50] <richi> I have a question.
 302 [2010-05-27 16:50:51] <matz> stevenb: I mean, instead of someone forcibly deciding (without doing the work).
 303 [2010-05-27 16:50:52] <mark> stevenb: I think it's an interesting discussion.  I don't know if we've gotten any sort of consensus, but I will say that I want to help break logjams, and am happy for people to CC: me if things get stuck.
 304 [2010-05-27 16:51:06] <mark> richi: OK, go ahead?
 305 [2010-05-27 16:51:08] <stevenb> ok
 306 [2010-05-27 16:51:24] <richi> Should we close the 4.3 branch?  Should we close branches at all or simply stop doing releases?  STOP
 307 [2010-05-27 16:51:44] <matz> The difference between "close branch" and "stop doing releases" being?
 308 [2010-05-27 16:51:52] * mark would simply stop doing releases, keeping the branches open for regression fixes forever.  STOP.
 309 [2010-05-27 16:52:03] <richi> Make sure the branch doens't get worse (whcih it doens't when no commits are made to it)
 310 [2010-05-27 16:52:05] <jsm28> Closing a branch means we no longer track bug status in Bugzilla.
 311 [2010-05-27 16:52:25] <richi> Over time old branches get nearly no testing, so they I guess get worse instead of better over time
 312 [2010-05-27 16:52:37] <matz> If there are commits to them, yes.
 313 [2010-05-27 16:52:52] <jsm28> Maybe if there were better ways of tracking that a bug exists on old branches without showing it as "open" in a default search and without a 4.3/4.4/4.5/4.6/4.7/4.8 marker in the summary, there would be no need to close branches.
 314 [2010-05-27 16:52:57] <matz> So, IMO: yes we should close branches.
 315 [2010-05-27 16:53:27] <jsm28> I'm certain releases still make sense and lots of people use them, even if more people do get them from various distributors.
 316 [2010-05-27 16:53:43] <jsm28> But for old branches we might stop making releases eventually.
 317 [2010-05-27 16:53:44] * stevenb thinks the marker in the summary is a Bad Thing -- often hides the actual subject of the bug
 318 [2010-05-27 16:54:25] <mark> OK, I want to try to answer at least one more question before the hour is up.
 319 [2010-05-27 16:54:41] <mark> There are a series of questions on the Wiki page about modular GCC and plug-ins and GFDL/GPL, etc.
 320 [2010-05-27 16:54:56] <richi> I like to comment on plug-ins
 321 [2010-05-27 16:54:58] <mark> The general thrust of all these is "can we do more modern programming techniques in GCC"?
 322 [2010-05-27 16:55:04] <mark> richi: OK, give me a minute, please?
 323 [2010-05-27 16:55:07] <richi> sure
 324 [2010-05-27 16:55:28] <mark> Whether that's literate programming for docs, or C++ for structuring code, or plug-ins to allow third-party use of GCC, etc.
 325 [2010-05-27 16:55:41] <mark> These are all techniques that are now mainstream coding approaches -- but not in GCC.
 326 [2010-05-27 16:55:59] <mark> I believe, unambiguosly, that we must move in this direction.  We do not have to jump on a bandwagon, but we must move.
 327 [2010-05-27 16:56:13] <mark> Furthermore, we must not let the FSF stop us from moving.
 328 [2010-05-27 16:56:20] <iant> FORK!
 329 [2010-05-27 16:56:20] <iant> sorry
 330 [2010-05-27 16:56:32] <mark> I think we've been too timid in pressing forward.
 331 [2010-05-27 16:56:35] <mark> And we includes me.
 332 [2010-05-27 16:56:53] <mark> I think it's time for us to start saying "look, these things are going to happen" and do them.
 333 [2010-05-27 16:56:54] <stevenb> it includes all those who talk to RMS/FSF in the name of the gcc community
 334 [2010-05-27 16:57:07] <mark> I think the FSF will get on board.
 335 [2010-05-27 16:57:12] <mark> OK, that's my long answer.  STOP.
 336 [2010-05-27 16:57:15] <matz> (I think moving "forward" (whereever that is) for the sake of moving is not very worthwhile)
 337 [2010-05-27 16:57:15] <dnovillo> mark: i agree completely.
 338 [2010-05-27 16:57:20] <jsm28> The FSF has responsibility for legal issues, but is bound by the Mission Statement just as much as the GCC maintainers are, in particular "Patches will be considered equally based on their technical merits.".  So if something is only controversial on technical grounds and does not engage legal issues, opinions from FSF people have no special status and technical decisions are ultimately up...
 339 [2010-05-27 16:57:20] <jsm28> ...to maintainers and the SC.  STOP.
 340 [2010-05-27 16:57:50] <stevenb> matz: do you have the feeling that gcc is moving for the sake of moving on some front?
 341 [2010-05-27 16:57:55] <mark> jsm28: I agree.
 342 [2010-05-27 16:58:00] <matz> stevenb: For some things, yes.
 343 [2010-05-27 16:58:16] <stevenb> matz: could you give an example?
 344 [2010-05-27 16:58:30] <matz> Plugins.  (really, I'm sorry to say, but it is as it is to me)
 345 [2010-05-27 16:58:38] <stevenb> ok, an example !plugins
 346 [2010-05-27 16:58:40] <stevenb> :)
 347 [2010-05-27 16:59:24] * stevenb likes plugins, for the record, but thinks that the way it's done in gcc now is too much
 348 [2010-05-27 16:59:24] <iant> plugins are not there "for the sake of moving;" they have real uses cases for real people
 349 [2010-05-27 16:59:25] <matz> Literate programming, when it would entail more than opening comments with '/**'
 350 [2010-05-27 16:59:45] <richi> We see patches adding plugin hooks in performance sensitive areas.  And
 351 [2010-05-27 16:59:46] <richi> plugins wanting access to all details of GCC.  I think we have to be
 352 [2010-05-27 16:59:46] <richi> very careful here to not generate a maintainance nightmare.  I think
 353 [2010-05-27 16:59:46] <richi> plugins are very badly architected and we should severely restrict what
 354 [2010-05-27 16:59:46] <richi> interfaces we expose.
 355 [2010-05-27 16:59:49] <apinski> question from me: when is 4.6's stage 1 ends?
 356 [2010-05-27 16:59:53] <jsm28> Moving for the sake of accessibility to new contributors trained in modern coding practices has a genuine benefit, even if not a direct technical one.
 357 [2010-05-27 16:59:53] <sabre> a few vocal people on the list aside, are there any "success stories" for plugins?
 358 [2010-05-27 17:00:10] <jsm28> Dehydra/Treehydra is the obvious plugins success story.
 359 [2010-05-27 17:00:11] <iant> sabre: we are using them successfully internally
 360 [2010-05-27 17:00:13] <stevenb> sabre: they have their uses,
 361 [2010-05-27 17:00:14] * mark agrees with richi; "dlopen" is not a plugin API. :-)
 362 [2010-05-27 17:00:23] <sabre> iant: ah, didn't know that, ok
 363 [2010-05-27 17:00:42] <richi> modularity will help us close down some of it I guess
 364 [2010-05-27 17:00:52] <mark> iant: Can you say what you're doing with them?  Analysis?  Or optimization?  Or both?
 365 [2010-05-27 17:00:54] <jsm28> I think by "literate programming" we are referring to an extremely light version.  Extracting comments, full documentation for options in .opt files, for example.
 366 [2010-05-27 17:01:08] <jsm28> We're not referring to Knuth-style writing something that is first a book and second a program.
 367 [2010-05-27 17:01:11] <stevenb> richi: i think we should allow plugins at different levels, not one plugin taking over control over all of gcc
 368 [2010-05-27 17:01:13] <iant> thread safety analysis, the work that is on the annotalysis branch or whatever it is called in the main repository
 369 [2010-05-27 17:01:22] <mark> iant: Thanks.
 370 [2010-05-27 17:01:44] <tromey> mozilla uses plugins for a lot of things, via treehydra STOP
 371 [2010-05-27 17:01:45] <iant> we also have a plugin which disables warnings in certain cases, e.g., in code which is not currently being edited by the user
 372 [2010-05-27 17:01:45] <matz> jsm28: I even have strong reservations against docbook markup in comments.
 373 [2010-05-27 17:01:48] <iant> that one is not widely used, though
 374 [2010-05-27 17:01:48] <mark> OK, well it looks like our hour is up.  I have to get to another meeting, though of course I'm happy for people to keep discussing things.
 375 [2010-05-27 17:01:57] <iant> mark: thanks for doing this
 376 [2010-05-27 17:01:59] <mark> For me, this was very useful.  I appreciate people participating.
 377 [2010-05-27 17:02:03] <stevenb> yes, thanks mark et al.
 378 [2010-05-27 17:02:05] <mark> Do we think we should do it again in a month or two?
 379 [2010-05-27 17:02:12] <iant> yes
 380 [2010-05-27 17:02:20] <iant> subject to your time constraints, obviously, but yes
 381 [2010-05-27 17:02:29] <mark> Anyone want to vote "no"?  (That's OK -- no reason to be shy.)
 382 [2010-05-27 17:02:43] <jsm28> matz: I claim we want to put extracted text in our main Texinfo manuals and so would encourage that rather than docbook, but whoever writes the code has a big say....
 383 [2010-05-27 17:02:43] <dnovillo> i vote yes
 384 [2010-05-27 17:03:05] <TobFZJ> No - I man yes - well. (Yes, do a RM meeting again.) STOP
 385 [2010-05-27 17:03:13] <stevenb> matz: the message is: beat them to it
 386 [2010-05-27 17:03:23] <matz> jsm28: Indeed :)
 387 [2010-05-27 17:03:27] <matz> stevenb: yeah yeah :-)
 388 [2010-05-27 17:03:41] <mark> OK, thanks a lot everyone!  Joseph, Richi, thank you both especially!
 389 [2010-05-27 17:03:58] <jsm28> Can someone now get the topic back to its normal gccbot-updated state?
 390 [2010-05-27 17:03:59] <stevenb> jsm28: re. c front end to own dir: you also mentioned last year that there is something with c-common that has to be resolved before the C front end can be moved into its own directory
 391 [2010-05-27 17:04:10] <dnovillo> mark: are you going to publish the minutes?
 392 [2010-05-27 17:04:13] <stevenb> jsm28: this had something to do with things in c-common that do not belong there
 393 [2010-05-27 17:04:14] <apinski> general question: with the amount of bug reports, how do we reduce the numbers?
 394 [2010-05-27 17:04:17] <jsm28> stevenb: c-common.c *shouldn't* include c-tree.h, but that doesn't block a move.
 395 [2010-05-27 17:04:19] <iant> regress
 396 [2010-05-27 17:04:20] <stevenb> jsm28: but i forgot the details
 397 [2010-05-27 17:04:21] <stevenb> ah
 398 [2010-05-27 17:04:24] <iant> %regress
 399 [2010-05-27 17:04:36] <iant> there is no gccbot....
 400 [2010-05-27 17:04:41] <jsm28> stevenb: It would simply be a file including "../c/c-tree.h", making it more obvious it's something it shouldn't be doing than it is at present.
 401 [2010-05-27 17:04:54] <TobFZJ> Two questions: 4.6 stage 1 will end when ? (asked by apinski). And: Will ther be a GCC Summit 2010?
 402 [2010-05-27 17:05:09] <richi> TobFZJ: stage 1 will end when it will end
 403 [2010-05-27 17:05:15] <stevenb> jsm28: because if c-common.c needs something from c-tree, then this thing should be in c-common.h or in a hook?
 404 [2010-05-27 17:05:16] <jsm28> The summit is a question for ajh.
 405 [2010-05-27 17:05:17] <dnovillo> TobFZJ: yes to your 2nd question.  october, most likely
 406 [2010-05-27 17:05:29] <apinski> dnovillo: october now, I thought September
 407 [2010-05-27 17:05:35] <TobFZJ> richi: That's a perfect timing :-)
 408 [2010-05-27 17:05:45] <jsm28> stevenb: Yes.  Or a function with the same name in C and C++, different implementations, although we should probably move away from that approach.
 409 [2010-05-27 17:05:46] <richi> TobFZJ: yep - we'll try hard to make it
 410 [2010-05-27 17:05:48] <iant> we do not have a very good summit, alas
 411 [2010-05-27 17:05:48] <dnovillo> apinski: that's the latest from ajh (~2 weeks ago)
 412 [2010-05-27 17:05:49] =-= mark has changed the topic to ``Trunk status -- stage 1 ||  Still 103 regressions in 4.3, 100 in 4.4, 104 in 4.5 and 121 in 4.6 (ssb)''
 413 [2010-05-27 17:05:52] <matz> apinski: Nope, obtober is the last info ajh sent
 414 [2010-05-27 17:06:02] <apinski> I need to get on that mailing list again
 415 [2010-05-27 17:06:05] <stevenb> jsm28: ok, thanks for the clarification!
 416 [2010-05-27 17:06:13] <jsm28> stevenb: The real bugs are when we have a function with the same name, *different prototype*, and c-common.c calls it with the C parameters.

Attached Files

To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.

You are not allowed to attach a file to this page.