On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote:
> "Up-porting" CAN'T be forgotten because it is done "automagically" vía
> mercurial merges. That is the point...
So developer A checks in a fix on 2.7, then gets sidetracked before
forward porting it.
When does it make it to 3.2 or the main devel
Jesus Cea wrote:
> On 03/02/11 13:04, Nick Coghlan wrote:
>> On Thu, Feb 3, 2011 at 10:37 AM, Jesus Cea wrote:
>>> In fact, "up-porting" is usually better, because you don't have to think
>>> if you must downport or not. Versión "n+1" is always a superset of
>>> versión "n". So you "up-port" *ALWA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 10:54, Nick Coghlan wrote:
> On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote:
>> "Up-porting" CAN'T be forgotten because it is done "automagically" vía
>> mercurial merges. That is the point...
>
> So developer A checks in a fix on 2.7, t
Le mercredi 02 février 2011 à 11:47 -0500, Barry Warsaw a écrit :
> >One issue it raises is the difficulties caused by freezing the trunk for
> >releases. Instead they advocate creating the release branch at the point of
> >the release candidate instead of freezing trunk. There are issues I
> >cur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 11:19, M.-A. Lemburg wrote:
> I don't understand why the developers have to follow the tools and
> not the tools the developers.
Well, the tool is designed for a particular workflow. If you do
something else, you are fighting the tool and
Hi,
When a patch is attached to an issue, it is usually a patch for the last
stable release or to trunk (2.7 or 3.2 trunk). The problem is that
latter the patch doesn't apply to trunk anymore and the author have to
update its patch. Sometimes, we ask to update a patch six months or one
year after
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 12:52, Victor Stinner wrote:
> It would be nice to create a branch for each issue (or each attached to
> an issue?)
Change "branch" to "temporal clone".
I support this, but implementation would be non trivial.
I have missed forever about
Le vendredi 04 février 2011 à 13:08 +0100, Jesus Cea a écrit :
> I support this, but implementation would be non trivial.
Yes, it is non trivial, but it would be helpful :-)
> The problem is how to cope with security issues
As I wrote: if security matters, only core developers should be able to
> The problem now is that patches in the development branch are
> "forgotten" and not backported when appropiate
Sorry, do you have real examples of this?
> If we up-port, no patch is forgotten. The rule should be: "patches in
> n+1 are a SUPERSET of patches in n". With this rule, mercurial take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 13:15, Victor Stinner wrote:
>> Rebasing is good before committing to the "real" repository, but anybody
>> with a checkout clone will suffer.
>
> Why?
Rebasing alters history. It messes with the "inmmutable" nature of
history. Anybody wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 13:25, Antoine Pitrou wrote:
>
>> The problem now is that patches in the development branch are
>> "forgotten" and not backported when appropiate
>
> Sorry, do you have real examples of this?
None I can show just now :(. I do remember di
On Fri, Feb 4, 2011 at 1:50 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/02/11 13:15, Victor Stinner wrote:
>>> Rebasing is good before committing to the "real" repository, but anybody
>>> with a checkout clone will suffer.
>>
>> Why?
>
> Rebasing alters history
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 14:31, Tarek Ziadé wrote:
>> As a general rule, rebase should be done ONLY in personal clones not
>> shared by anybody. Or, in this particular case, a clone should be
>> automatically destroyed after merging to main development line.
>
> T
On Fri, Feb 4, 2011 at 2:48 PM, Jesus Cea wrote:
..
> I am not sure what way is better. Keeping ALL the history would be
> interesting anyway, but most of my tiny commits would break the build (I
> commit everytime I stop for thinking, pee, whatever. It is like autosave
> in my text editor), so th
Le vendredi 04 février 2011 à 14:48 +0100, Jesus Cea a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/02/11 14:31, Tarek Ziadé wrote:
> >> As a general rule, rebase should be done ONLY in personal clones not
> >> shared by anybody. Or, in this particular case, a clone should b
On Fri, 04 Feb 2011 13:25:54 +0100, Antoine Pitrou wrote:
> > The problem now is that patches in the development branch are
> > "forgotten" and not backported when appropiate
>
> Sorry, do you have real examples of this?
I can't point you at specific examples, but I remember reading issues
where
On Fri, Feb 4, 2011 at 14:31, Tarek Ziadé wrote:
> That's why I think it's much cleaner to work with mq to build a clean
> single-commit patch, even if a clone may be used for temporary states
> and sharing.
>
> We are experiencing merge hell right now in Distutils2, as the
> contributor list gro
On Feb 4, 2011, at 9:44 AM, Dirkjan Ochtman wrote:
> I think extra clones per issue could work for some larger issues that
> require lots of work, but I don't think the
> every-small-feature-on-a-branch model (as practiced in Twisted, IIRC)
> is particularly helpful. On the other hand, I do think
Tarek Ziadé wrote:
> You are building a patch and submit it to reviews (in roundup or in a
> clone or retvield etc). You get feedback and you refine the patch.
>
> I don't think you want to keep that history, e.g. "changing this and
> that in my patch after feedback from MrX about Y"
>
> The main
On Sat, Feb 5, 2011 at 12:30 AM, R. David Murray wrote:
>> That's a theoretical and IMO naïve point of view. In practice, there are
>> many changesets that will not "up-port" cleanly and will need manual
>> work. The work will not be much less than with down-porting.
>
> As Nick pointed it, it is
On Fri, Feb 4, 2011 at 11:57 PM, Tarek Ziadé wrote:
> I'd rather have a best practice guide *now* and refine it later. e.g.
> "how to contribute to python via mercurial."
>
> I think we have people here with a decent expertise of Mercurial that
> can come up w/ this, even if it's changed after.
Y
On Feb 04, 2011, at 04:35 PM, M.-A. Lemburg wrote:
>Tarek Ziadé wrote:
>> You are building a patch and submit it to reviews (in roundup or in a
>> clone or retvield etc). You get feedback and you refine the patch.
>>
>> I don't think you want to keep that history, e.g. "changing this and
>> that
On Feb 04, 2011, at 04:10 AM, Jesus Cea wrote:
>If we up-port, no patch is forgotten. The rule should be: "patches in
>n+1 are a SUPERSET of patches in n". With this rule, mercurial takes
>care of everything (a patch in n+1 can 'undo' a patch up-ported from n,
>if needed, keeping the rule).
I'm n
Am 04.02.2011 17:03, schrieb Barry Warsaw:
>>> The worse possibility is that fixes may be applied to maintenance
>>> branches and not to the main line of development, leading to
>>> regressions after upgrades (since the associated tests wouldn't be
>>> forward ported either).
>>
>>That is not goin
On Feb 04, 2011, at 12:35 PM, Victor Stinner wrote:
>I am already using a DVCS (git-svn) to work on Python, especially for my
>work on Unicode. It is just impossible to work on an huge change on
>trunk, it changes too fast. A SVN branch should be created or a DVCS
>tool should be used. I prefer DV
On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote:
> On the other hand, if *any* forward port naturally picks up all the
> missed forward ports, then the Mercurial perspective starts to make
> more sense (especially if the merge is able to exploit the DAG in
> order to make fewer mistakes).
That's
Le vendredi 04 février 2011 à 17:25 +0100, Dirkjan Ochtman a écrit :
> On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote:
> > On the other hand, if *any* forward port naturally picks up all the
> > missed forward ports, then the Mercurial perspective starts to make
> > more sense (especially if the
On Feb 04, 2011, at 05:25 PM, Dirkjan Ochtman wrote:
>On Fri, Feb 4, 2011 at 16:49, Nick Coghlan wrote:
>> On the other hand, if *any* forward port naturally picks up all the
>> missed forward ports, then the Mercurial perspective starts to make
>> more sense (especially if the merge is able to e
On Fri, Feb 4, 2011 at 17:31, Antoine Pitrou wrote:
>> That's exactly the idea of the Mercurial way. You type hg merge
>> and it will merge everything from the other branch that
>> hasn't been merged yet (where both "blocking", in svnmerge
>> terminology, and merging count as having been merged).
On Fri, Feb 4, 2011 at 17:36, Barry Warsaw wrote:
> Doesn't that mean that the person doing the forward port will potentially have
> to review a lot more code than the fix they specifically want to make?
Potentially, yes. I would imagine in many cases (let's not count 2.x
-> 3.x for now) the merg
On Feb 04, 2011, at 05:46 PM, Dirkjan Ochtman wrote:
>But if not, this should incentivize people to forward-port their own
>changes, which is a good thing, IMO.
Sure. I guess my question is, what do *you* do in that case? Are you blocked
because I didn't do my job properly? Can you tell your m
On Fri, Feb 4, 2011 at 17:51, Barry Warsaw wrote:
> Sure. I guess my question is, what do *you* do in that case? Are you blocked
> because I didn't do my job properly? Can you tell your merge to ignore my
> change so you can keep making progress, complete your patch, and send me a
> nastygram t
Am 04.02.2011 18:03, schrieb Dirkjan Ochtman:
> On Fri, Feb 4, 2011 at 17:51, Barry Warsaw wrote:
>> Sure. I guess my question is, what do *you* do in that case? Are you
>> blocked
>> because I didn't do my job properly? Can you tell your merge to ignore my
>> change so you can keep making pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 16:49, Nick Coghlan wrote:
> On the other hand, if *any* forward port naturally picks up all the
> missed forward ports, then the Mercurial perspective starts to make
> more sense (especially if the merge is able to exploit the DAG in
> ord
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 16:58, Barry Warsaw wrote:
> I guess this is just a Mercurial quirk I'll have to get used to. It's not
> something I ever bother with in Bazaar because, while those intermediate
> commits are still part of the merged branch's history, it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 17:03, Barry Warsaw wrote:
> Given that this workflow is a social one, encouraged but not imposed by the
> technology, how will we respond when things are done The Wrong Way? What are
> the effects if someone forgets and commits a patch to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 17:31, Antoine Pitrou wrote:
> How do you "block"?
What patches in "3.2" you don't want in "3.3"?.
Remember the rule: "Patches in n+1 are a SUPERSET of patches in n". But
a patch in "n+1" can undo a patch in "n", keeping this rule true al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 17:51, Barry Warsaw wrote:
> Sure. I guess my question is, what do *you* do in that case? Are
> you blocked because I didn't do my job properly? Can you tell your
> merge to ignore my change so you can keep making progress, complete
> yo
On 2/4/2011 1:41 PM, Jesus Cea wrote:
Remember the rule: "Patches in n+1 are a SUPERSET of patches in n".
This is simply not true of 2.7 versus 3.2. 3.x is a fork off of 2.x at
about 2.6. There are many 2.7-only bugs whose patches should not be
forward ported, either 'by hand' or by auto m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 20:55, Terry Reedy wrote:
>> Remember the rule: "Patches in n+1 are a SUPERSET of patches in n".
>
> This is simply not true of 2.7 versus 3.2. 3.x is a fork off of 2.x at
> about 2.6. There are many 2.7-only bugs whose patches should not
> Look at issue 11089. It is applied in 2.7 and 3.1, but it can't be
> applied to 3.2 because we are in RC state now. Now, somebody *MUST*
> remember to apply this patch when the 3.2 branch in open again. That is
> a waste of mental energy for nothing.
That's because Raymond chose to break the us
On Feb 4, 2011, at 6:36 PM, Antoine Pitrou wrote:
>
>> Look at issue 11089. It is applied in 2.7 and 3.1, but it can't be
>> applied to 3.2 because we are in RC state now. Now, somebody *MUST*
>> remember to apply this patch when the 3.2 branch in open again. That is
>> a waste of mental energy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/11 00:36, Antoine Pitrou wrote:
>
>> Look at issue 11089. It is applied in 2.7 and 3.1, but it can't be
>> applied to 3.2 because we are in RC state now. Now, somebody *MUST*
>> remember to apply this patch when the 3.2 branch in open again.
Le samedi 05 février 2011 à 01:00 +0100, Jesus Cea a écrit :
> > Someone could sit and produce a
> > written proposal evaluating the various possibilities, and we can
> > iterate from that.
>
> I do agree.
Can you try writing said document?
___
pytho
Am 03.02.2011 00:16, schrieb Barry Warsaw:
> On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote:
>
>> I suspect this problem with the preferred DVCS workflow is going to
>> cut fairly heavily into the number of bug fixes applied to the
>> maintenance branches.
>
> I'd be really surprised if it *has
> Indeed. Mainline is the only branch where we *know* most patches need
> to be applied. It also means that people can contribute while
> maintaining only a single checkout, rather than necessarily needing
> all active versions.
Notice that you'll automatically will have all active versions
availa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/11 01:07, Antoine Pitrou wrote:
>
> Le samedi 05 février 2011 à 01:00 +0100, Jesus Cea a écrit :
>>> Someone could sit and produce a
>>> written proposal evaluating the various possibilities, and we can
>>> iterate from that.
>>
>> I do agree
Am 04.02.2011 10:54, schrieb Nick Coghlan:
> On Fri, Feb 4, 2011 at 1:17 PM, Jesus Cea wrote:
>> "Up-porting" CAN'T be forgotten because it is done "automagically" vía
>> mercurial merges. That is the point...
>
> So developer A checks in a fix on 2.7, then gets sidetracked before
> forward porti
Le samedi 05 février 2011 à 02:18 +0100, Jesus Cea a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/02/11 01:07, Antoine Pitrou wrote:
> >
> > Le samedi 05 février 2011 à 01:00 +0100, Jesus Cea a écrit :
> >>> Someone could sit and produce a
> >>> written proposal evaluating
Am 04.02.2011 13:25, schrieb Antoine Pitrou:
>
>> The problem now is that patches in the development branch are
>> "forgotten" and not backported when appropiate
>
> Sorry, do you have real examples of this?
If you really want to know, I can dig them out. I'm fairly sure I owe
10 or 20 backports
Am 04.02.2011 19:41, schrieb Jesus Cea:
> On 04/02/11 17:31, Antoine Pitrou wrote:
>> How do you "block"?
>
> What patches in "3.2" you don't want in "3.3"?.
It happens in more cases than you think.
I sometimes develop two versions of a patch, one for the maintenance
branch which preserves backw
51 matches
Mail list logo
