This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: source mgt....[_HAS_ gcc relevance]



       It's true that mostly only a small number of people work on any
       given chunk of a large piece of software, but I strongly
       disagree that they should go off by themselves and merge into
       the main tree only when they're done, as the default mode of
       development.


Well, my ideal is that changes to the mainline should occur only
_after_ they have verifiably passed all the available tests on a wide
range of platforms (a process that can be fully automated) and the
changes have passed senior engineer reviews (a process that can be
facilitated by substantial automated assistance).  Mainlines should
increase in quality in a strictly monotonic fashion -- that's the
essence of what "gatekeeper management" is all about.  Neither GCC nor
lk have that property -- though better tools can do much to put us
there.  With good tools, the release manager can ultimately be
replaced by shell scripts.


       As a user of the kernel, I am also concerned about the apparent
       trend toward having many variant trees not for development, but
       to present divergent sets of features and bugfixes.  It strikes
       me as a recipe for user confusion and vendor malfeasance.

Don't pull back -- go Furthur.  There's a lot of good side effects
that can be obtained by giving each _end-customer_ (or nearly so)
their own source fork -- not _only_ feature divergence, but also (and
especially) risk management and emergency preparedness.  Divergent
fixes and bugfixes aren't the end of the world.  On the contrary,
they're a good thing.

Centralizing (in a small number of vendors) binary preparation for
millions (or for thousands of enterprises) is, in and of itself,
"vendor malfeasance".  It creates vulnerabilities, slows down
responsiveness to customer needs, and enables monopolistic "lock-in".

The idea that either of these projects is way ahead of the other in
terms of process is, I think, not quite right.  They're both about
equally far from the ideal.

But sure, I'm describing an ideal point that's on the horizon -- not
a change you should try to make next week.  Just something to stroll 
towards.

-t


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]