Re: [Development] Please warn of force pushes...
On Tuesday 23. April 2013 09.46.03 Thiago Macieira wrote: On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote: [...] Change the branch name when the policy changes. i really wouldn't want to do that. But you're not offering a better solution either. You're just dismissing the problem completely: indeed, my solution is dismissing this NON-problem. Thank you for your opinion. Since I'm entitled to mine, we have an impasse. Just to throw in another opinion: I'm with Ossi on this one. We use the term WIP for stuff that is in flux. Changes in Gerrit prefixed with WIP imply random rebasing for example. Unless you're talking to the author you shouldn't make any assumptions. If we use the term wip also in branches, why not apply the same rules (keep hands off unless you're working with the folks) ? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
+1 for this. I met with this non-fast-forward case today. Sometimes, when people are mirroring a git repo, and git push --mirror doesn't work well for some reason. Then git push --all is a second choice, and this non-fast-forward will break git push --all. Better to warn of those force pushes. And even better to not do it in the main repo, like qt, qt5/*. And these kinds of big feature branch, if needs to have non-fast-forward push, maybe better to happen in a clone repo. It's very easy to do before the gerrit ages. Regards, Liang From: development-bounces+liang.qi=digia@qt-project.org [development-bounces+liang.qi=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Monday, April 22, 2013 3:14 AM To: development@qt-project.org Subject: [Development] Please warn of force pushes... My server just let me know: From git://gitorious.org/qt/qtbase 60fbb00..c5a3cfa dev- dev 1f3a67e..f78842a stable - stable ! [rejected]winrt - winrt (non-fast-forward) PLEASE let the mailing list know every time a history rewrite is about to happen and when it has happened in one of the main repositories. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
Hi,
there has been quite many comments about why rebasing might be complicated for
some people, but so far I think the advantages for the WinRT branch has not
been highlighted. So let me try to summarize why the team thinks that it is
beneficial to do so:
a) We do lots of changes upstream and get them back into the WinRT branch very
quickly this way. Of course we could do that via other means, but
b) the team bases on dev and wants to ensure that integration back into dev
will be a simple step once the port is stable enough. Without any/much
rebasing/squashing/history-rewrite efforts when time has come. For both
previous ports (Android and iOS) there have been lots of discussions how to
get things back properly, where so far we failed to make everyone happy.
Taking a rebased branch seemed to be beneficial here.
I do agree to Kai that having some official guidelines will benefit future
ports as well, but I also fail to see why the WinRT branch now is so much of a
difference compared to other ones. Maybe we should move the discussion into a
generic one with WinRT being one example beside others instead of complaining
about WinRT, but getting to no conclusion after all.
BR,
Maurice
-Original Message-
From: development-bounces+maurice.kalinowski=digia@qt-project.org
[mailto:development-bounces+maurice.kalinowski=digia.com@qt-
project.org] On Behalf Of Oswald Buddenhagen
Sent: Tuesday, April 23, 2013 7:12 PM
To: development@qt-project.org
Subject: Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to
test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the
man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my branches.
I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are
not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I
am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits
coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing
branches
are acceptable in the mainline repositories, provided they are clearly
marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Wednesday 24 April 2013 06:28:43 Kalinowski Maurice wrote: Hi, there has been quite many comments about why rebasing might be complicated for some people, but so far I think the advantages for the WinRT branch has not been highlighted. So let me try to summarize why the team thinks that it is beneficial to do so: a) We do lots of changes upstream and get them back into the WinRT branch very quickly this way. Of course we could do that via other means, but Normaly, the way git was designed, is to use merges for this workflow. In principle, rebasing should only be used for private branches. And the winrt is not private. Not only it is public, but it is even part of the main repsitory. You should only merge with dev when you really need a change from dev. You may also cherry pick, if you only want a single change. Rebasing is harmfull if anyone else if following this branch. So I would recommand doing merges instead of rebasing. b) the team bases on dev and wants to ensure that integration back into dev will be a simple step once the port is stable enough. Without any/much rebasing/squashing/history-rewrite efforts when time has come. Merging should be even easize than rebasing. For both previous ports (Android and iOS) there have been lots of discussions how to get things back properly, where so far we failed to make everyone happy. Taking a rebased branch seemed to be beneficial here. I think the proper way to do it is to have the relevant maintainers of the code look at the non-trivial patches already now. I beleive it was one of the problem with the android port, that it is a bit like a code drop when reviewing was too late. I do agree to Kai that having some official guidelines will benefit future ports as well, but I also fail to see why the WinRT branch now is so much of a difference compared to other ones. Maybe we should move the discussion into a generic one with WinRT being one example beside others instead of complaining about WinRT, but getting to no conclusion after all. I encourage to use merges instead of rebasing. That say, git has many possible workflows, and if rebasing is really better for the people working on winrt, then let it be. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Wed, Apr 24, 2013 at 09:23:54AM +0200, Olivier Goffart wrote: Normaly, the way git was designed, is to use merges for this workflow. In principle, rebasing should only be used for private branches. And the winrt is not private. Not only it is public, but it is even part of the main repsitory. You should only merge with dev when you really need a change from dev. You may also cherry pick, if you only want a single change. Rebasing is harmfull if anyone else if following this branch. So I would recommand doing merges instead of rebasing. the thing is, if you want to merge to a mainline, each of your commits needs to comply with all of a mainline's policies, because your commits will become part of the mainline. this is not the case with winrt (and previous ports). therefore, the discussion is already over at this point. but rebasing has other advantages, too. one is that conflicted merges are inherently evil. therefore, the fewer merges, the better. the second is that a clean workflow (discussion with concerned maintainers, submission for the right branch, integration, forward-merging) has a way too high latency. consequently, the teams take many shortcuts, which violates pretty much every aspect of the commit policy and produces a terrible history. rebasing is the only way to get that straightened out without holding up the ad-hoc development. the last (and imo deciding) point is: if the concerned team likes this workflow, it is good. it's ridiculous to make concessions for hypothetical drive-by contributors. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 08:02:23PM +0200, Koehne Kai wrote:
Hi guys,
don't want to stop your discussion, but personally I see that mainly as a
documentation issue. Surely having some convention about branch names (and
sticking to it) would help, but even better would be to put the details about
the branches on something that shows up very high in google qt git branches
:) Right now there's
http://qt-project.org/wiki/Branches
which is qt creator only. We should have the same for qt.git, or list both on
the page.
this is a very good point.
in fact, there were/are several branches in qtbase where i simply don't
know what they are for (which is kinda suboptimal, given that i'm
supposed to be one of the admins). i have repeatedly been chasing behind
people to find out who is responsible and whether a branch is still
relevant.
i made some additions to the existing page. i expect the branch owners
to fill the sections with meat and add any missing branches (from other
repos than qtbase).
also, somebody with a better overview of the wiki structure should
add/replace the category tags to mark the page as relevant also for qt,
and link the page appropriately.
Regards
Kai
PS: Yet another example: http://gcc.gnu.org/svn.html, where all the gcc
branches are described.
From: development-bounces+kai.koehne=digia@qt-project.org
[development-bounces+kai.koehne=digia@qt-project.org] on behalf of Oswald
Buddenhagen [oswald.buddenha...@digia.com]
Sent: 23 April 2013 19:11
To: development@qt-project.org
Subject: Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to
test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the
man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my
branches. I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are
not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I
am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing
branches
are acceptable in the mainline repositories, provided they are clearly
marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On 04/22/2013 05:11 PM, Thiago Macieira wrote: And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. Just in case somebody is interested: We are rebasing the 4.8-bb10 branch as well. I don't think this is an issue in practice, because not many people are using it and the ones who do know that already I would assume... Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 17.44.41, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 08:11:22AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.59.27, Oswald Buddenhagen wrote: And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. while not entirely invalid, i don't think this is of particular concern. somebody who joins the work on a project is supposed to be talking to the respective people. Not necessarily. They may have simply found out about the branch due to our public posts and blogs, so they're just looking around. Hypothetically, there are also people maybe working for companies who cannot yet disclose their interest on WinRT. sure These people need to be warned that the branch rebases. why would they? they can adapt once it happens. i mean, it's a bit of a surprise, but it doesn't change much in the end. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx sounds over-engineered to me. and unnecessarily restrictive, as the policy may change ad-hoc as things progress. Change the branch name when the policy changes. i really wouldn't want to do that. i don't think we should put any more energy into discussing this matter. the only action point is documenting on the wiki that wip/ branches (winrt should have had that prefix, obviously) may be subject to history rewriting. The wip prefix does help to identify that the branch is not ready and could be unstable. If most wip branches rebase, then we can declare that the entire wip/ prefix is subject to rebasing. If there's just one, I'd rather have it clearly marked. i'd say it's perfectly mixed, so just wip/ is not a sufficient discriminator. and i really don't think we need one, because i don't see it as a practical problem. In any case, why does this branch rebase? Can't they live with merges? well, the wip/ branches often have rather lax review policies (often bypassing domain experts in the case of platform ports) and no CI. this results in a messy history (and sometimes bug fixes that actually need to be applied to more stable branches to start with). therefore i'm advocating history reshaping and early mainline submission of generic fixes (which of course means rebasing in turn). it worked really well for ios, sort of well for android (they went for a squash merge instead of rebasing, which kind of made sense given the history of the import), and appears to be going just fine for winrt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On terça-feira, 23 de abril de 2013 11.18.33, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote: Not necessarily. They may have simply found out about the branch due to our public posts and blogs, so they're just looking around. Hypothetically, there are also people maybe working for companies who cannot yet disclose their interest on WinRT. sure These people need to be warned that the branch rebases. why would they? they can adapt once it happens. i mean, it's a bit of a surprise, but it doesn't change much in the end. Because the surprise is quite big. If you do a git pull --rebase or git pull, it might blow up after dozens lines have scrolled out. People don't pay attention to the output of the fetch part. Though I have to grant that novice users are unlikely to be following those branches in the first place. But then, we're left with somewhat knowledgeable users following the branches, so they are more likely to have extra commits and then have no clue on how to rebase their work on top of the rebased base. I, for one, will not touch any of the rebasing branches, not even to test them. It's too much work to rebase on top of a moving base. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx sounds over-engineered to me. and unnecessarily restrictive, as the policy may change ad-hoc as things progress. Change the branch name when the policy changes. i really wouldn't want to do that. But you're not offering a better solution either. You're just dismissing the problem completely: i'd say it's perfectly mixed, so just wip/ is not a sufficient discriminator. and i really don't think we need one, because i don't see it as a practical problem. I'm sorry, just because it is not a problem for you and for the handful of developers working on that branch, it does not mean it's not a problem for anyone. And maybe it isn't the case for the winrt branch, but who knows what other branches we may have in the future. Sorry, I want it to be a policy that either: a) branches do not rebase (no force pushes allowed, period) or b) branches that do rebase have rebasing in their names I'd much rather it be option (a). In any case, why does this branch rebase? Can't they live with merges? well, the wip/ branches often have rather lax review policies (often bypassing domain experts in the case of platform ports) and no CI. this results in a messy history (and sometimes bug fixes that actually need to be applied to more stable branches to start with). therefore i'm advocating history reshaping and early mainline submission of generic fixes (which of course means rebasing in turn). it worked really well for ios, sort of well for android (they went for a squash merge instead of rebasing, which kind of made sense given the history of the import), and appears to be going just fine for winrt. If they're bypassing the reviewers and bypassing the CI, why do they need to be in the main Git repositories in Gerrit in the first place? Especially if they're bypassing the CI, they could and should just use a repository elsewhere. When the branch is ready, it will be submitted as individual patches to be reviewed by the regular reviewers, maybe starting the work branch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the man
page first and paying attention to the ASCII Art graphs.
Besides, that's unwieldy. I don't carry a handful of commits in my branches. I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
Change the branch name when the policy changes.
i really wouldn't want to do that.
But you're not offering a better solution either. You're just dismissing
the
problem completely:
indeed, my solution is dismissing this NON-problem.
Thank you for your opinion. Since I'm entitled to mine, we have an impasse.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing branches
are acceptable in the mainline repositories, provided they are clearly marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
We no longer mark the repository by giving it a different path, so they now can
be confused and someone might think that they are official and mainline. But to
be honest, granting extra privileges to some people is less of a problem than
rebasing.
Besides, the fact that we made it worse in one aspect is not a justification
for accepting it elsewhere too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the
man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my branches.
I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing branches
are acceptable in the mainline repositories, provided they are clearly
marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
Hi guys,
don't want to stop your discussion, but personally I see that mainly as a
documentation issue. Surely having some convention about branch names (and
sticking to it) would help, but even better would be to put the details about
the branches on something that shows up very high in google qt git branches
:) Right now there's
http://qt-project.org/wiki/Branches
which is qt creator only. We should have the same for qt.git, or list both on
the page.
Regards
Kai
PS: Yet another example: http://gcc.gnu.org/svn.html, where all the gcc
branches are described.
From: development-bounces+kai.koehne=digia@qt-project.org
[development-bounces+kai.koehne=digia@qt-project.org] on behalf of Oswald
Buddenhagen [oswald.buddenha...@digia.com]
Sent: 23 April 2013 19:11
To: development@qt-project.org
Subject: Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my branches. I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing branches
are acceptable in the mainline repositories, provided they are clearly marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
Hi, Am 22/04/2013 03:14, schrieb Thiago Macieira: My server just let me know: From git://gitorious.org/qt/qtbase 60fbb00..c5a3cfa dev- dev 1f3a67e..f78842a stable - stable ! [rejected]winrt - winrt (non-fast-forward) PLEASE let the mailing list know every time a history rewrite is about to happen and when it has happened in one of the main repositories. as this branch is rebased (not merged) regularly (Ossi does the actual rebase) forced pushes happen quite often. We will send out a notice before these happen in the future, sorry for not thinking of that. Cheers, Olli ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
At 22/04/2013 03:14, from Thiago Macieira: My server just let me know: From git://gitorious.org/qt/qtbase 60fbb00..c5a3cfa dev - dev 1f3a67e..f78842a stable - stable ! [rejected] winrt - winrt (non-fast-forward) PLEASE let the mailing list know every time a history rewrite is about to happen and when it has happened in one of the main repositories. Hi, Thiago, Looks like the sync script(s) is running on your server(from codereview to gitorious)? Is it possible also sync the code to github for mirror? github is much more popular than gitorious. Thanks. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
+1 This would make quick code browsing much easier; Gitorious' interface is rather cumbersome. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Apr 22, 2013, at 3:44 AM, Qi Liang liang...@digia.com wrote: At 22/04/2013 03:14, from Thiago Macieira: My server just let me know: From git://gitorious.org/qt/qtbase 60fbb00..c5a3cfa dev- dev 1f3a67e..f78842a stable - stable ! [rejected]winrt - winrt (non-fast-forward) PLEASE let the mailing list know every time a history rewrite is about to happen and when it has happened in one of the main repositories. Hi, Thiago, Looks like the sync script(s) is running on your server(from codereview to gitorious)? Is it possible also sync the code to github for mirror? github is much more popular than gitorious. Thanks. Regards, Liang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Sun, Apr 21, 2013 at 06:14:08PM -0700, Thiago Macieira wrote: My server just let me know: From git://gitorious.org/qt/qtbase 60fbb00..c5a3cfa dev- dev 1f3a67e..f78842a stable - stable ! [rejected]winrt - winrt (non-fast-forward) PLEASE let the mailing list know every time a history rewrite is about to happen and when it has happened in one of the main repositories. why exactly would you care? everyone working on the respective branch is somehow involved into the rebase process. everyone else doesn't need to care/can reset --hard if they actually have a checkout. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On segunda-feira, 22 de abril de 2013 07.44.31, Qi Liang wrote: Looks like the sync script(s) is running on your server(from codereview to gitorious)? No, this is no the codereview-gitorious sync. This is just updating the repositories so the statistics script can run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On segunda-feira, 22 de abril de 2013 10.15.43, Oswald Buddenhagen wrote: why exactly would you care? everyone working on the respective branch is somehow involved into the rebase process. everyone else doesn't need to care/can reset --hard if they actually have a checkout. Because everyone working is somehow missing people who don't know that. If a branch is in the main repositories, everyone who cloned qtbase has it. That means you have an undeterminate number of people who might be looking at it. Do not rebase it. No, really. Please don't rebase a branch in the main repositories. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Mon, Apr 22, 2013 at 07:16:22AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 10.15.43, Oswald Buddenhagen wrote: why exactly would you care? everyone working on the respective branch is somehow involved into the rebase process. everyone else doesn't need to care/can reset --hard if they actually have a checkout. Because everyone working is somehow missing people who don't know that. so? If a branch is in the main repositories, everyone who cloned qtbase has it. That means you have an undeterminate number of people who might be looking at it. Do not rebase it. No, really. Please don't rebase a branch in the main repositories. you didn't provide any reasons. as far as i'm concerned, the push policy for all non-mainline branches (in particular those without a CI) is entirely up to the discretion of their owners. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On segunda-feira, 22 de abril de 2013 16.25.30, Oswald Buddenhagen wrote: as far as i'm concerned, the push policy for all non-mainline branches (in particular those without a CI) is entirely up to the discretion of their owners. And where is it documented for winrt? Anyway, I'm asking for a policy change: do not rebase any branch in the main repositories. And the reason is that a lot of people have those branches by simple virtue of cloning the main qtbase. It's not possible to be sure everyone knows the policies of each branch. Therefore, we define one only: no rebase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Mon, Apr 22, 2013 at 07:48:07AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.25.30, Oswald Buddenhagen wrote: as far as i'm concerned, the push policy for all non-mainline branches (in particular those without a CI) is entirely up to the discretion of their owners. And where is it documented for winrt? why should it be? Anyway, I'm asking for a policy change: do not rebase any branch in the main repositories. And the reason is that a lot of people have those branches by simple virtue of cloning the main qtbase. It's not possible to be sure everyone knows the policies of each branch. so? Therefore, we define one only: no rebase. you are effectively asking for a second gerrit instance then. maybe rethink that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On segunda-feira, 22 de abril de 2013 16.59.27, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 07:48:07AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.25.30, Oswald Buddenhagen wrote: as far as i'm concerned, the push policy for all non-mainline branches (in particular those without a CI) is entirely up to the discretion of their owners. And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. Anyway, I'm asking for a policy change: do not rebase any branch in the main repositories. And the reason is that a lot of people have those branches by simple virtue of cloning the main qtbase. It's not possible to be sure everyone knows the policies of each branch. so? See above. Therefore, we define one only: no rebase. you are effectively asking for a second gerrit instance then. maybe rethink that. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Mon, Apr 22, 2013 at 08:11:22AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.59.27, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 07:48:07AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.25.30, Oswald Buddenhagen wrote: as far as i'm concerned, the push policy for all non-mainline branches (in particular those without a CI) is entirely up to the discretion of their owners. And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. while not entirely invalid, i don't think this is of particular concern. somebody who joins the work on a project is supposed to be talking to the respective people. Therefore, we define one only: no rebase. you are effectively asking for a second gerrit instance then. maybe rethink that. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx sounds over-engineered to me. and unnecessarily restrictive, as the policy may change ad-hoc as things progress. i don't think we should put any more energy into discussing this matter. the only action point is documenting on the wiki that wip/ branches (winrt should have had that prefix, obviously) may be subject to history rewriting. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On segunda-feira, 22 de abril de 2013 17.44.41, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 08:11:22AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.59.27, Oswald Buddenhagen wrote: And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. while not entirely invalid, i don't think this is of particular concern. somebody who joins the work on a project is supposed to be talking to the respective people. Not necessarily. They may have simply found out about the branch due to our public posts and blogs, so they're just looking around. Hypothetically, there are also people maybe working for companies who cannot yet disclose their interest on WinRT. These people need to be warned that the branch rebases. Therefore, we define one only: no rebase. you are effectively asking for a second gerrit instance then. maybe rethink that. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx sounds over-engineered to me. and unnecessarily restrictive, as the policy may change ad-hoc as things progress. Change the branch name when the policy changes. i don't think we should put any more energy into discussing this matter. the only action point is documenting on the wiki that wip/ branches (winrt should have had that prefix, obviously) may be subject to history rewriting. The wip prefix does help to identify that the branch is not ready and could be unstable. If most wip branches rebase, then we can declare that the entire wip/ prefix is subject to rebasing. If there's just one, I'd rather have it clearly marked. In any case, why does this branch rebase? Can't they live with merges? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
