Hi Oswald, On 10/07/2013 10:29 AM, Oswald Buddenhagen wrote: > the difference is that these branches are maintained by the same people, > or at least that those maintaining the stable branch are *paid* to > actively cherry-pick from the unstable branch. > you proposed an open-for-all branch with very low quality criteria, and > basically maintaining the status quo of the master branch. but mutt > already has that anything-goes branch: it's called trac. when you make > an actual hg branch of it, it will be a fork, and master will be > abandoned for good.
Well, it seems each of us uses different definition of "fork" in this context (personally I stick to the definition from wikipedia http://en.wikipedia.org/wiki/Fork_(software_development) ). Anyway, even if you call the open-for-almost-all branch a "fork", I can't agree with the fact that the trac currently acts like such a branch - there is a really huge difference between picking all working patches from track (and applying them to the upstream branch) and just checking out such already existing branch. Moreover why do you think the master will be abandoned for good in case such branch will be introduced? It somehow doesn't fit well with your statement, that there are people (possibly *paid*) maintaining the stable branch - why would they stop maintaining it? Let me apologize, but I don't see any reason for them to act like that. > this is a complete distraction from the actual problem. > we're not at QA or even releasing yet. we are at (not) developing. you > can't release something that simply isn't there (this is also where your > analogy to distros fails). > now you may argue that the current unstable branch should be simply > promoted to stable. maybe you're right. so release. what then? Don't overthink the problem. The guys maintaining the stable branch would just do what they did till now. The open-for-almost-all branch wouldn't need to have any releases - look at the frequency of changes in trac and you'll end up with impression that everyone interested with commit rights for this open-for-almost-all branch wouldn't have any interest to break things up. Just let the things flow - if it wouldn't work, nothing will happen compared to the current state (the stable branch and trac wouldn't be affected by any means). So I don't see any reason why not to go for it. It seems so viable - if only for proof of community engagement. > as for the orga theory: when you look at all those big projects with > many involved people, you'll always find teams with (informal) internal > hierarchies: a leader (or a few of them) and possibly a bunch of lesser > qualified (or more time-constrained) minions. the point is that you > don't get anywhere with just minions. Of course, but this "hidden" hierarchy is often based solely on the very-own opinion of each person. Such opinion is often not even publicly disclosed (even not to other minions). And the point is, that it really doesn't have to be disclosed. Keep in mind that this kind of "freedom" pushes the development forward and makes the project vital. >>> that means that anyone who'd want to make major functionality >>> improvements would have to start with substantial refactoring. >> >> Well, then he should be aware of the fact, that this is not mutt's goal >> if I'm not mistaken. Today one can create a simple MUA in python in >> about one day satisfying his own needs. So, it would be a bit ill-judged >> if someone really wanted to make a huge refactorization or alike of mutt. >> > hmmm? do you even know what refactoring is? Maybe I just forgot to add a few words to the last sentence. I meant it like this: So, it would be a bit ill-judged if someone really wanted to make a huge refactorization or alike of mutt only to prepare it for major functionality improvements. Regards -- Jan Pacner
