[Trac-dev] Development policy proposal

Seeking to improve software quality and move toward a solid 0.11 release, the 
following developer policy is proposed:

 1 Anything beyond a 'trivial' bugfix requires a branch.
 2 A branch must be reviewed and approved by another developer before merging 
to trunk.  If something is committed to trunk with insufficient review, 
anyone can backout changes, preferably to a branch.
 3 Branches should have a purpose statement on t.e.o under TracDev/Branches 
and an announcement to trac-dev.

Votes/Comments?

Eli
------------------. "If it ain't broke now,
Eli Carter         \                  it will be soon." -- crypto-gram
retracile <at> gmail.com `-------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Development policy proposal

On Sunday 02 September 2007 4:26:50 pm Eli wrote:
> Seeking to improve software quality and move toward a solid 0.11 release,
> the following developer policy is proposed:
>
>  1 Anything beyond a 'trivial' bugfix requires a branch.
>  2 A branch must be reviewed and approved by another developer before
> merging to trunk.  If something is committed to trunk with insufficient
> review, anyone can backout changes, preferably to a branch.
>  3 Branches should have a purpose statement on t.e.o under TracDev/Branches
> and an announcement to trac-dev.
>
> Votes/Comments?

+1

Comments:
 1  I expect 'trivial' new features to use a branch, since they should include 
unittests for the new functionality and documentation.
 2 'backout to a branch' means reverting a changeset on trunk, creating a new 
branch, and committing the reverted changeset to the new branch.  While not 
strictly required, I do see that as a more polite way of reverting someone 
else's change.
 3 Branches for 'small' changes may skip the wiki page, but there should still 
be an announcement to trac-dev to gather reviewers.

It is critical that we all make the effort to review other developers' 
branches in a timely manner, and provide useful, constructive feedback as 
early in the development process as possible.

[Trac-dev] Re: Development policy proposal

On 9/3/07, Eli <retracile <at> gmail.com> wrote:
> >  1 Anything beyond a 'trivial' bugfix requires a branch.
> >  2 A branch must be reviewed and approved by another developer
> >  before merging to trunk.  If something is committed to trunk with
> >  insufficient review, anyone can backout changes, preferably to a
> >  branch.
> >  3 Branches should have a purpose statement on t.e.o under
> >  TracDev/Branches and an announcement to trac-dev.
> >
> > Votes/Comments?

+1. I'd have liked this process before the security merge. The feedback
I did get, from osimons and cboos IIRC, was invaluable, but more eyes
means better code.

Here are some more points I suggest we think about adding:

 - Requests for code review must be responded to within a timely manner.

 - Purpose statements/designs should be reviewed as early as possible.
 - Feedback must be constructive, with well reasoned arguments to back
   up your position.
 - Each branch should contain just the changes required to implement
   your proposal. This makes the reviewers life easier which in turn
   makes yours easier.

These are more just guidelines than anything but I think they're critical to
this whole thing working. Particularly the first point.

[Trac-dev] Re: Context object should have perm info (0.11dev)

osimons wrote:
> On Aug 27, 2:52 am, osimons <oddsim...@gmail.com> wrote:
>   
>> The issue was to figure out how to render arbitrary wiki markup
>> without a request object - which was no problem with 0.10 wiki_to_...
>> () methods. Now with the context and the new security branch, calling
>> the formatter (via format_to_html()) it will somewhere deep down say
>> that there is no req.perm to use when rendering links.
>>     
>
> Actually, as macros have always received the req object, I suppose it
> never really has been safe to render wiki markup outside a request
> context...
>   

Well, that's historical. I think it's a perfectly valid use case to 
render wiki markup outside of the realm of a web request, e.g. off-line 
wiki-to-html or wiki-to-xyz batch conversion, data mining, etc.

In Trac 0.10, a Request object was used to carry the template data 
(req.hdf), the user information (req.authname) for basic permission 
checks, and the req.path_info was extensively used to identify the 
resource being processed. In addition, the req was and is still used to 
convey the chrome data and probably a few more things.
I tried to move some of those to the WikiContext object, with a bit more 
formalism at the level of how a resource was identified (the stack of 
realm/id pairs, plus the version info), but again this ended in a mix of 
different concerns as the rendering details were grafted on.

[Trac-dev] Re: Development policy proposal

Am 03.09.2007 um 02:23 schrieb Alec Thomas:
> On 9/3/07, Eli <retracile <at> gmail.com> wrote:
>>>  1 Anything beyond a 'trivial' bugfix requires a branch.
>>>  2 A branch must be reviewed and approved by another developer
>>>  before merging to trunk.  If something is committed to trunk with
>>>  insufficient review, anyone can backout changes, preferably to a
>>>  branch.
>>>  3 Branches should have a purpose statement on t.e.o under
>>>  TracDev/Branches and an announcement to trac-dev.
>>>
>>> Votes/Comments?
>
> +1. I'd have liked this process before the security merge. The  
> feedback
> I did get, from osimons and cboos IIRC, was invaluable, but more eyes
> means better code.
>
> Here are some more points I suggest we think about adding:
>
>  - Requests for code review must be responded to within a timely  
> manner.

s/must/should :P

While this is great in theory, there's really no way to enforce this.  
We're all volunteers here, and most of us don't have tons of spare  
time on our hands, so the best thing that can be done to get timely  
feedback is to write up a really good summary of the changes, the  
objectives, the design, etc.

[Trac-dev] Re: Development policy proposal

Eli wrote:
> On Sunday 02 September 2007 4:26:50 pm Eli wrote:
>   
>> Seeking to improve software quality and move toward a solid 0.11 release,
>> the following developer policy is proposed:
>>
>>  1 Anything beyond a 'trivial' bugfix requires a branch.
>>  2 A branch must be reviewed and approved by another developer before merging 
>> to trunk.  If something is committed to trunk with insufficient review, 
>> anyone can backout changes, preferably to a branch.
>>  3 Branches should have a purpose statement on t.e.o under TracDev/Branches 
>> and an announcement to trac-dev.
>>
>> Votes/Comments?
>>     

Sorry Eli, I'm -1 on this proposal, as I don't think that 
/systematically/ creating branches for non-trivial bugfixes will be 
productive.
Right now, a bug fix already requires you to reproduce the issue, fix 
it, check that it works well and that you didn't break anything else as 
a side-effect, write a commit log message and close the ticket. If you 
add to this the need to create a branch, make an announcement on 
trac-dev, wait for feedback ... well, it's simply not realistic.
A policy of intermediate strictness would be to have to post a patch on 
the corresponding ticket before committing, eventually creating the 
ticket first if there's none yet. As a matter of fact, this is already 
what I do quite often. You get notified of this activity if you follow 
trac-tickets (everybody here *do* follow trac-tickets, right?).

[Trac-dev] Re: Development policy proposal

Christian Boos wrote:
> Eli wrote:
>> On Sunday 02 September 2007 4:26:50 pm Eli wrote:
>>   
>>> Seeking to improve software quality and move toward a solid 0.11 release,
>>> the following developer policy is proposed:
>>>
>>>  1 Anything beyond a 'trivial' bugfix requires a branch.
>>>  2 A branch must be reviewed and approved by another developer before merging 
>>> to trunk.  If something is committed to trunk with insufficient review, 
>>> anyone can backout changes, preferably to a branch.
>>>  3 Branches should have a purpose statement on t.e.o under TracDev/Branches 
>>> and an announcement to trac-dev.
>>>
>>> Votes/Comments?
>>>

+1 for me.  I'm also +1 with the comments from Alec and Christopher

> Sorry Eli, I'm -1 on this proposal, as I don't think that 
> /systematically/ creating branches for non-trivial bugfixes will be 
> productive.
> Right now, a bug fix already requires you to reproduce the issue, fix 
> it, check that it works well and that you didn't break anything else as 
> a side-effect, write a commit log message and close the ticket. If you 
> add to this the need to create a branch, make an announcement on 
> trac-dev, wait for feedback ... well, it's simply not realistic.

While this does get into the subject definition of "trivial," I think 

[Trac-dev] Re: Development policy proposal

On 9/4/07, John Hampton <pacopablo <at> pacopablo.com> wrote:
> We're kind of in this spot right now with regards to the context stuff
> and security.  Security got merged, and I'm glad for that, but it's only
> finished for the wiki.  It needs to be extended to the tickets, and
> needs to be done before a release.

Ticket proper has been done for a couple of weeks:

	http://trac.edgewall.org/changeset/5958

Query and report are to come.

I don't think I'd do anything differently with security under this
proposed scheme.

I requested review of the branch, got some feedback from cboos and
osimons and integrated them. People had around two weeks to review the
branch before I merged it. The fact that only a couple of people
actually did, illustrates my previous point about how people
*must*/*should* ;) take the time time to review changes if this entire
system is to work.

I specifically kept the differences small by limiting the changes to the
Wiki subsystem. This was so it would be easier to review, and
consequently any problems found would be relatively easy to fix.

The real problem was that my life became significantly busier and I was
unable, until recently, to dedicate enough time to it. Not much one can
do about RL intruding.

[Trac-dev] Perforce integration question

[Trac-dev] Re: Perforce integration question

Ce message et ses pièces jointes (le "message") est destiné à l'usage    
exclusif de son destinataire.                                            
Si vous recevez ce message par erreur, merci d'en aviser immédiatement   
l'expéditeur  et de le détruire ensuite. Le présent message  pouvant  
être altéré à notre insu,  CALYON Crédit Agricole CIB                             
ne peut pas être engagé par son contenu. Tous droits réservés. 

This message and/or any  attachments (the "message") is intended for     
the sole use of its addressee.                                            
If you are not the addressee, please immediately notify the sender and    
then destroy the message.  As this message and/or any attachments may 
have been altered without our knowledge,  its content  is not legally 
binding on CALYON Crédit Agricole CIB. All rights reserved.