2015-10-28 14:50 GMT+01:00 Aaron Durbin adurbin@google.com:
That presupposes there is work going on in those branches that is desired to be pushed back into another branch. Anyone can very much port forward something if they so choose. That's the point of the branching mechanism.
What is your proposal for dealing w/ inconvenience? I haven't seen a modicum of change in that area. In fact, what we have seen is more boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and maintained) to be practical to keep around, remove them. For real. Claiming that we can stuff them "in branches" is a cop-out, because they're still dead.
That's also why I proposed to go with tags for releases: When people are motivated enough to dig out the old stuff and make it work again, there should be some incentive to bring them up to current standards. Then they can get back into master. If somebody is spearheading such an effort and provides test resources, I think there's even some willingness to help with some of the more mechanical tasks - like cleaning out #include "file.c" stuff, but the motivation is rather hard to get by when it's unclear if the code is ever used again.
People can still take any old commit (tagged, branched, or not) and do their own thing on github - however I think we're setting standards by what we do. Opening branches encourages to keep basing work on them, instead of considering snapshots to be just that.
My main objection to dropping things was that the motivation by the proponents always looked very similar to "this is inconvenient to me right now, let's get rid of this". If we were consequential in following up every such sentiment by everyone, we'd probably ship a single file, COPYING.
Patrick
-
Patrick Georgi