[Twisted-Python] Reminder: Twisted 10.1 scheduled for early June

2010-05-26 Thread Jonathan Lange
Hello all,

I and my lovely assistant Glyph intend to cut a release of Twisted
10.1 on the 5th and 6th of June. That's in eleven days.

If you would like to help us do that, please fix one of:
  http://twistedmatrix.com/trac/ticket/3998
  http://twistedmatrix.com/trac/ticket/4345
  http://twistedmatrix.com/trac/ticket/4320

Or review tickets: http://twistedmatrix.com/trac/report/15

Thanks,
jml

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread Glyph Lefkowitz

On May 23, 2010, at 10:35 PM, exar...@twistedmatrix.com wrote:

> On 23 May, 12:26 am, gl...@twistedmatrix.com wrote:
>> So: thoughts?  Does this make sense as a policy change for facilitating 
>> the development of major new features or consolidating behavior- 
>> changing fixes into easier-to-understand units?
> 
> So, to summarize, we could stage our code using more than just two 
> branches (trunk + feature branch) in order to make larger changes easier 
> to understand for reviewers while still making each change to trunk a 
> coherent unit.

That's about the size of it.

> This sounds fine to me.  We need to work out some details (like, for 
> example, I'm not sure trying to do this using subversion is such a good 
> idea, and we want the process to be documented somewhere so we don't 
> have a repeat of #886), but I think we should try it and see what 
> happens.

Great.  I propose some core committers try it out however makes sense to them, 
on whatever the next obvious thing to try it on is.  Rather than try to 
document the whole process up front, please just spell out what you expect the 
reviewer to do on each ticket placed into review this way, and we'll document 
the process after we've nailed down something that works.

> Of course, someone needs to work on something big before we'll have a 
> chance to try it.  I'm not yet convinced that `URLPath` is a good case 
> for this, though.  It's very little code, and a complete 
> reimplementation (if even such a thing is needed) will likewise be very 
> little code.  Also, I don't think a complete reimplementation is needed 
> here.

Yeah, like I said: I just grabbed that example because it was handy, not 
because I thought it was particularly appropriate.  I don't even have anything 
in particular in mind.  I actually wanted to bring this up while we were 
*between* major things, so that we could avoid discussions of specific problems 
with a current branch or feature (once something's in the middle of being 
implemented it develops a life of its own, and this is often an emotional 
context in which to talk about process changes).

> Going back to the proposed workflow change, we should also be sure 
> there's a clear condition under which the integration branch should be 
> merged to trunk.  And ideally we should still try to keep the lifespan 
> of these things as short as possible.

My proposed criterion would be that the integration branch has an associated 
ticket, with links to a list of all other tickets expected to be a part of it.  
When all tickets on that list are closed, it can be merged at any time.  This 
would, however, leave the door open for a reviewer to say "# is okay to 
merge, but based on my review really need to consider # before it can be 
merged to trunk, so please add that to the integration branch list".  Of 
course, in the interest of keeping these lifespans short, this suggestion 
should be used sparingly.  But it would be good for things like "update the 
documentation and examples" or "I noticed that the old system had feature X, we 
really need to keep parity with that before we deprecate it".

I still like the idea of a final sanity check, but based on jml's feedback 
about Launchpad perhaps it would be best if we kept that step optional.  
Especially since I can't think of a clear set of guidelines for reviewers at 
that stage.  (I mean, they *should* check for all the same stuff one normally 
checks for; coverage, documentation, etc, but they *shouldn't* block the merge 
from going to trunk while they re-audit every changed line of code, as that 
defeats the purpose of having incremental reviews in the first place.)___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread Glyph Lefkowitz

On May 24, 2010, at 7:42 AM, Jonathan Lange wrote:

> FWIW, we've been doing this on Launchpad for some years and it works out well.

Good to know.

> As a rule, we don't have the final "sanity check" review, since we
> have robot minions that check for conflicts and that the tests pass.

This is useful information.  Our buildbot isn't *quite* PQM, but then... 
there's a strong case to be made that Jean-Paul is himself a robot.

> Using a DVCS would make it much easier. For example, Bazaar has
> plugins like loom and pipeline that are designed to manage a stack of
> changes.

Looms still scare me a bit, but my intent was definitely that a DVCS (and yes, 
most likely specifically bzr) would be involved.  If you have any particular 
insight as to how one might go about doing that, it would be helpful.

For practical purposes, until the bzr-ness of the buildbots is more exposed, I 
was thinking that developers could work in bzr but push changes into svn 
branches for testing.  Does that sound workable?

> Also, +1 on the documentation.

I think we should continue this discussion after somebody has done at least one 
branch like this.___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread Laurens Van Houtven
I've said something in #twisted but I hadn't read this reply yet, so for
sake of saving this for posterity, I agree with jml here. I think we're
mostly being bitten because of a lack of software tools, in the form of svn
and trac. Disclaimer: I really dislike svn since I never figured out how
Combinator works. I really dislike trac.

So, for the rest of this e-mail, let's pretend we're implementing a big new
feature since that's the thing I tried to do to some extent.

Major stuff could be a blueprint on Launchpad. Blueprints match a branch for
the "big feature". So, we have the Twisted blueprint
quantum-transmogrification and a branch
lp:~lvh/twisted/quantum-transmogrification.

>From that branch I create a bunch of branches of review units (if it turns
out it's too big, I just branch again for a new review unit). So, I want to
do something with entanglement:
lp:~lvh/twisted/quantum-transmogrification-entanglement, and it's good, so
someone reviews and sends it back.

lp's merge proposals let you do the code review in arbitrarily small chunks.
So if the thing I do next
is lp:~lvh/twisted/quantum-transmogrification-ftl-travel, and it turns out
FTL travel is really really hard so I need two smaller
branches lp:~lvh/twisted/quantum-transmogrification-tunnels
and lp:~lvh/twisted/quantum-transmogrification-ansible. Both are good, so
they get put back into ~lvh/twisted/quantum-transmogrification-ftl-travel.

Each review would verify that all children (if any) have also been
reviewed. So, the final review is pretty small, as suggested :-) This does
not limit a developer's freedom to branch at will, because code review is
opt-in (merge proposal), not opt-out. If you don't do it, that code in that
branch isn't covered by a previous review, and must be reviewed later.

How exactly code review coverage would work is somewhat of an open question
and it's the obvious failure in this system. We use it in production and it
turns out to not be a problem, because people always end up doing two
things:

1) always branch at least once from the first branch off trunk (so branch
off lp:~lvh/twisted/quantum-transmogrification). Net
result: lp:~lvh/twisted/quantum-transmogrification only introduces code in
the form of merges.
2) always do code review on branches being merged into your first branch off
trunk (so everything merged into lp:~lvh/twisted/quantum-transmogrification
has to be reviewed already)

Note that our merges into trunk are automagic. If it's merged into a direct
branch off of trunk and it satisfies some qualities (such as full test
coverage :)), it gets put into trunk, and that gets pushed to production
servers. No human interaction. Scary at first, but then you realize humans
were already involved in the QC process extensively at every point -- doing
it this way just makes them take testing more seriously :)

I think a bug would be similar except the root would not be a blueprint but
a bug.


Laurens
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread Konrads Smelkovs
It would already be a big step forward if the naming convention could
be addressed. Unfortunately the web vs. web2 thing really puts code
archeologists in a confusion if the incremental numbered module policy
is applied, because it appears that web2 > web but it is actually not.
code archeology could be less of an issue if some of the following
would be found good:
1) for existing developers, release notes would keep them up to date.
Also, perhaps a migration guide on how to move from old to new would
ensure people are using latest and greatest.
2) write a module guide for new developers, saying don't use X because
it is old. Use Y
3) once new module is there, raise decpreciation for old module. As
the old could be still valid, make a warning suppression mechanism.



2010/5/23, Glyph Lefkowitz :
> The nice thing about Twisted's compatibility policy is that developers, and
> even users, very rarely have problems when installing a new version of
> Twisted.  While this is a nice benefit, the current strategy of developing
> features in a compatible way does have a couple of costs, and I'd like to
> see if we can address them without giving up the benefit.  I have a
> suggestion for a process tweak which would hopefully mitigate some of the
> difficulties which arise due to the compatibility policy.
>
> When we add a new feature that supersedes an older one, or fix a bug in
> Twisted that involves changing behavior, the developer fixing it has to come
> up with a new name.  If we have several behavior-changing bugfixes in the
> same subsystem, that means that developers using Twisted may have to learn
> about 3 different symbol names.  Since we tend to avoid just suffixing names
> with numbers (for good reason, I think), they won't have to learn Bicycle,
> Bicycle2, Bicycle3, they'll have to learn Bicycle, then Footcycle, and
> finally Velocipede, and somehow infer that Velocipede is the newest/best
> name that they should be using, by reading the (hopefully clear, concise)
> warnings that come out of their unit tests.
>
> This came up again recently on a ticket about URLPath,
> , where a contributor
> suggested that it would be better to make a whole new module because it's
> easier for external developers to learn about that then learn about an
> individual method change.  This of course raises the question: if we're
> going to have a whole new URL class, shouldn't it fix the (numerous) *other*
> bugs that we know about in URLPath?
>
> Up until now the objection to doing things this way is that it results in
> gigantic branches which are intractable to review.  That's a good objection,
> but it leaves us with a false dichotomy; reliable software and painless
> upgrades with a random scattershot of new features that are hard to
> understand, or coherent iterations of technology which can't be effectively
> reviewed, and therefore can't be effectively quality controlled.
>
> I propose that we get the best of both worlds by changing the way we do
> reviews slightly.  Right now every code review needs to be done on an entire
> feature going to trunk, and _all_ of the code going to trunk needs to be
> reviewed at once.  I suggest that instead, we create "integration branches"
> for sensible constellations of features, and have a two-stage review
> process.
>
> For example, let's say I want to work on making URLPath good.  There are
> several tickets addressing it:
>
> 
> 
> 
>
> For the sake of argument, let's all pretend these are all deeply
> interrelated and involve changes to behavior of existing methods.  I think
> that is sort of true of most of these, but it would be far too verbose to
> talk about *how*, and get bogged down in that discussion.
>
> First, I'd make an integration ticket, let's call it #ABCD, describing how
> these features are related and a brief outline of the new API I propose
> which resolves them.
>
> Then I'd create an integration branch from trunk, for that ticket.  From the
> #ABCD branch, I'd create a branch for #2093, and put it up for review.  The
> reviewer would review #2093 as usual, citing any test coverage issues,
> documentation issues, etc.  After the usual review process, when I get an
> "OK to merge", I would merge #2093 *to the #ABCD branch*, not trunk.
>
> I would repeat this process for #2094 and #2625, merging each to the #ABCD
> branch as they passed review.
>
> Finally, I'd put #ABCD itself up for review.  At this point the process
> would differ a bit.  Reviewers would be able to assume, at this point, that
> the potentially large body of code in #ABCD had already been reviewed, that
> the test cases were good, the documentation was reasonably clear, and the
> logic made sense.  This final review would be a quick sanity check, to make
> sure the tests still pass and that there are no 

Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread exarkun
On 08:44 am, gl...@twistedmatrix.com wrote:
>
>On May 24, 2010, at 7:42 AM, Jonathan Lange wrote:
>>Also, +1 on the documentation.
>
>I think we should continue this discussion after somebody has done at 
>least one branch like this.

Well, we did #886, right?

Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread Glyph Lefkowitz

On May 26, 2010, at 5:41 AM, Laurens Van Houtven wrote:

> Major stuff could be a blueprint on Launchpad. Blueprints match a branch for 
> the "big feature". So, we have the Twisted blueprint 
> quantum-transmogrification and a branch 
> lp:~lvh/twisted/quantum-transmogrification.

So, while I can definitely sympathize with a certain animosity towards trac, 
and I can appreciate the goals and sensibilities of launchpad, I will probably 
flat-out veto any required / process-driven usage of Launchpad blueprints.  
Bugs, features, enhancements, etc, are all units of work that need to be 
tracked, and it's better to have one kind of crummy interface for tracking 
_everything_ than three interfaces, even three good interfaces, for tracking 
little bits stuff in different ways according to arbitrary distinctions.  (As 
someone recently opined to me, Blueprints are a giant complicated interface for 
pasting the URL to a Google Wave into a text field.  We might as well skip the 
text field and just link straight to the conversation from a Trac ticket.)

> From that branch I create a bunch of branches of review units (if it turns 
> out it's too big, I just branch again for a new review unit). So, I want to 
> do something with entanglement: 
> lp:~lvh/twisted/quantum-transmogrification-entanglement, and it's good, so 
> someone reviews and sends it back.
> 
> lp's merge proposals let you do the code review in arbitrarily small chunks. 
> So if the thing I do next is 
> lp:~lvh/twisted/quantum-transmogrification-ftl-travel,

lp:~lvh... isn't a verb.  What do you do with that string? :)

> and it turns out FTL travel is really really hard so I need two smaller 
> branches lp:~lvh/twisted/quantum-transmogrification-tunnels and 
> lp:~lvh/twisted/quantum-transmogrification-ansible. Both are good, so they 
> get put back into ~lvh/twisted/quantum-transmogrification-ftl-travel.
> 
> Each review would verify that all children (if any) have also been reviewed. 
> So, the final review is pretty small, as suggested :-)


The review wouldn't verify that the parent had been reviewed, though.  If you 
started this process by writing a bunch of code in the q-t-f-t branch, *that* 
code would never have been reviewed; unless q-t-f-t needs to be reviewed in its 
entirety before landing on trunk.  Which is precisely what I'm trying to avoid.

> This does not limit a developer's freedom to branch at will, because code 
> review is opt-in (merge proposal), not opt-out. If you don't do it, that code 
> in that branch isn't covered by a previous review, and must be reviewed later.

This strikes me as placing a pretty nasty burden on the reviewer.  The reviewer 
has to figure out if there are any commits that went only to the integration 
branch, isolate them, review them, get that branch into an OK-it's-reviewed 
state, while meanwhile other developers might be committing stuff to that 
branch and changing its contents, both from regular working commits and from 
reviewed merges.  It sounds like a nightmare.  Maybe bzr makes it easier than 
it sounds, but it sounds bad enough that even a big improvement would still be 
pretty bad ;).

> How exactly code review coverage would work is somewhat of an open question 
> and it's the obvious failure in this system. We use it in production and it 
> turns out to not be a problem, because people always end up doing two things:

Who is "we"?  What is "production"?  Are you talking about Twisted or a 
hypothetical project which uses Twisted, or a fork of Twisted on Launchpad?  Is 
this a hypothetical project or a real proejct?  I am super confused.

> 1) always branch at least once from the first branch off trunk (so branch off 
> lp:~lvh/twisted/quantum-transmogrification). Net result: 
> lp:~lvh/twisted/quantum-transmogrification only introduces code in the form 
> of merges.

That's pretty much what I'm proposing, except I don't actually care whether 
they're merges or patches or individual commits, as long as they've cycled 
through code-review properly.

> 2) always do code review on branches being merged into your first branch off 
> trunk (so everything merged into lp:~lvh/twisted/quantum-transmogrification 
> has to be reviewed already)

And this is what we already do.

> Note that our merges into trunk are automagic.

(Again, who is "we", and by what mechanism are they automated?  Are you 
proposing that we do this, or are you stating that some other people do?)

> If it's merged into a direct branch off of trunk and it satisfies some 
> qualities (such as full test coverage :)), it gets put into trunk, and that 
> gets pushed to production servers. No human interaction. Scary at first, but 
> then you realize humans were already involved in the QC process extensively 
> at every point -- doing it this way just makes them take testing more 
> seriously :)

Human interaction of some kind should definitely be required for Twisted.  This 
is not just pushing some new widget to a web site; 

Re: [Twisted-Python] major changes, release engineering, and learning cost

2010-05-26 Thread Glyph Lefkowitz
On May 26, 2010, at 9:53 AM, exar...@twistedmatrix.com wrote:

> On 08:44 am, gl...@twistedmatrix.com wrote:
>> 
>> On May 24, 2010, at 7:42 AM, Jonathan Lange wrote:
>>> Also, +1 on the documentation.
>> 
>> I think we should continue this discussion after somebody has done at 
>> least one branch like this.
> 
> Well, we did #886, right?


I don't think that counts.  I meant that we've done at least one feature that 
*successfully* used a set of stacked branches.  (I hope "stacked" means what I 
think it means here, and not some other crazy bzr thing.)  #886 is more a 
description of the failure condition here than a success.

#886 had one half-hearted sub-ticket, #3811, which eventually got abandoned and 
had to wait until #886 was merged to trunk anyway.  And lots of other stuff 
that I wish had been added at the same time for a coherent unit of new 
functionality (like the high level API) was spun out into a separate ticket 
because it was too hard to review all at once.

The high-level ticket in this case is really sneakily hiding out here: 
.  (A few things are still 
open there but I doubt that this is still a good candidate for development 
under the proposed style.)


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python