On Tue, Feb 25, 2014 at 11:28:46AM -0800, Thiago Macieira wrote: > Em ter 25 fev 2014, às 20:09:41, Oswald Buddenhagen escreveu: > > > If it passes reliably within half an hour, no lockdown is necessary. The > > > lockdown is only necessary today so the people doing the merging don't > > > have to tear their hair out to keep track of two moving targets. > > > > eh? > > the merging goes from stable to dev, then a fast-forward to stable. > > from before the start of the merge, through the integration in dev, to the > > push, stable must be frozen. and the actual start would be delayed if an > > integration was already going on on stable. so we are still talking > > about an hour lockdown time on stable. > > Again, the main issue is passing the CI. If the CI is working reliably and we > can get stuff done quickly, it doesn't matter that there are more changes. > > The merges of the stable branch into the development branch will continue to > happen periodically. Nothing changes there. > > The big question is what happens at feature freeze. If the merging of dev > into > stable were quick and painless, we wouldn't be having this discussion. So my > point is: we're working around the root problem because we can't fix the root > problem right now. > we already established that merging from dev to stable is simply not working due to revdeps (which are a good thing in principle, see other thread). that's why it is forward merging + fast-forward downwards. to ensure the fast-forward, stable would need to be locked.
> I'm no longer disputing the use of branches, after Lars made his decision. I > just wanted to be clear on what we're actually doing. Let's move on. > good. i'm also just clarifying that you are still wrong, despite this being irrelevant now. :P > > > But I think you're suggesting something like this: > > > > > > A--B--C--D--> 5.3 > > > > > > \--E--F > > > > no, i'm suggesting this: > > > > A--B--C--D--E--F--> 5.3 > > \--C'--F' ^ shadow/v5.2 > > ^ v5.2 > > Sorry, this one has a fatal flaw: if F gets tagged, like you show, then it > would imply that E is also is in that release, which your graph shows it > isn't. > correct. that's why the tag would be a shadow, and not the real thing, and it would be an error-prone hack. whether it would still make sense would depend on the actual use cases we want to cover. > > > If F is tagged v5.3.1, then B is tagged "branchpoint-5.3.1". That means D > > > gets described as "branchpoint-5.3.1-2-gXXXXXX". > > > > to get this, on can simply use git merge-base. > > If it isn't merged, yes. But then when I do git describe on the 5.5 branch, > it > will tell me it's v5.2.1 + 10000 commits. > correct, "forward" describe would become useless. describe --contains would still return useful results, though, and i think that's what is more useful in practice (i suspect it's not the default only because it's more expensive). > > > Maybe it could be tagged "branchpoint-5.3.2". Maybe instead C should be > > > the > > > "Bump version" commit and be tagged. > > > > we could even guarantee that the version bump is the first commit - we are > > during source branch lockdown at the time anyway. > > but tagging that commit seems unnecessarily complex anyway. > > Not to mention that it sometimes fails to integrate, [...] > during the lockdown we could simply direct-push the bump. the risk that something goes wrong with that at this point is virtually non-existing. but anyway ... irrelevant. > > > I dislike duplicating the number of tags in the repository. It will > > > create confusion. > > > > we can give them a prefix, like forks/v5.2.0. still twice as many > > tags, but not really confusing. > > The number of tags creates the confusion, IMHO. You can't argue that having > them twice is more complex than having them once, all else being equal. > if you have the complexity of 1 and you make it more complex by .05 as a trade-off for a useful feature, that seems quite reasonable to me. > > > So I would prefer the merge back, since the duplication of commits > > > doesn't cause confusion, regardless of the number of them. > > > > when looking at a simple git log (or even worse a bit blame if you are > > unlucky), merged cherry-picks are always confusing, even if properly > > marked. the only worse thing is cherry-picks mixed with reverts. > > I don't agree. The git log is more complex, indeed, since it shows the > duplication, but each duplicated commit has the SHA-1 of the original commit > so you know what it meant. > the problem is assembling the topological order in the brain, thus enabling a reliable judgement which commit is in which release. almost nobody is able to visualize the precise graph, especially with duplicated/reverted commits (it's kinda indexed by summary, at least in my head). > What's more, it won't show on git blame: blame will choose one of the > two sides of the merge and display it. > > If it chooses the one from the mainline, unfortunately, it will still break > my > workflow above. > funny thing you are saying that, because for the "normal" (not release-bound) research workflow, choosing the picked version would be the worse outcome. i think this allows only one conclusion: merged cherry-picks (and reverts) are bad, and should be avoided if at all possible. so to come back to the starting point: i think we should continue to target the release branch directly. the burden for the developers isn't very big (actually, one can even argue that the burden being there is a good thing ... it discourages people from pushing for release), and it makes the discussion about merging back irrelevant (because then it is both harmless and required). > > > A reasonable developer is not what you get in the #qt channel. > > > > this is not an audience to optimize *our* repositories for. > > make a wiki page Building-Qt5-From-Git-For-Users and hand that out > > whenever somebody botches a git build, without further words. > > We can expect contributing developers to be reasonable and execute a few more > commands to get to the branch they want to be in. Plus, as I said, I truly > believe that even our devs should land on the currently stable branch at > first, > not the development one. > you didn't give good reasons for that position, though. > The non-contributing developers, however, are the vast majority. Writing wiki > pages isn't enough because people don't find them. It's amazing how many > things > are answered by a simple Google search, yet people don't do them. > i don't buy that argument. laziness/stupidity should not be rewarded in an environment that is supposed to be productive. if a nice RTFM link is not good enough for somebody, they deserve losing time. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development