Talk:Working Procedures
Need to tie this into The QA Process MJMcKay 02:38, 30 June 2010 (UTC)
Contents
Comments from PMC Head
1,2 - About Developer and Official Releases, please check the policy already established from PMC here: Release Strategy
5 - About "Commit and reversion rules (on trunk)" - I would recommend to keep it simple, allow PMC to apply the Release Commit Rules on trunk, you can see there the policies for revert in three levels (strict, bearable mandatory and recommended). The rules must be something evolutive.
6 - About "Maturity" - I think an experimental branch is needed different than trunk to allow people to contribute unstable or untested things, allowing such things on trunk (where most of developers are working fixing bugs) is a way to lead to dependency problems between valid needed commits that cannot be passed to release because of other incomplete dependant contributions
7 - About "Roles":
a) the number of committers required per branch is just a wish, requiring two is not feasible currently and discourage the creation of branch-per-developer probably the best approach with mercurial
b) I don't see the clear reason why the maintainers must be different (and we don't have enough people respecting the rules to promote such division)
c) PMC can (currently is allowed according to 3.2.1.3 on PMC Head Concept) ban people from trunk when they become disruptive to the process, it will be good to establish the number of breaks after a developer is considered disruptive, and probably establish a level of bans, i.e. firstly after N breaks developer is banned by two months, secondly after M breaks developer is banned by six months, finally after X breaks developer is banned for life
--CarlosRuiz_globalqss 04:18, 1 July 2010 (UTC)
Carlos, as PMC head you probably have a better idea of how many breaks it is possible for existing resources to deal with. So why don't you put in suggested real numbers instead of N, M and X? --Zeeshanhasan 06:15, 1 July 2010 (UTC)
- Thanks Zeeshan, I can make a proposal for number N, M, X. IMHO the issue is not about people breaking things, but people REFUSING to fix what they breaks, and people refusing to follow the rules. So we need to consider that on the numbers N, M, X. I like when a developer break something, and react quickly fixing (or reverting) when somebody else make him aware of the break. I would suggest for example N=5, M=3, X=2. --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
Reply to Comments from PMC Head
1,2: The idea here is change current Release Strategy
- Why? I invite you to join the PMC Release Group or at least PMC Release meetings and discuss the proposal there. --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
5: Current rules seem too strict and obviously do not align well with current developer way of working. Since "modifying" developers is difficult (we want to keep current developers, right?), we should modify the rules.
- Too strict? Can we discuss which rules on Release Commit Rules are strict instead of opening a new set? Why or which doesn't align with current developer way of working, most of the rules are just previously accepted ADempiere Best Practices, and these best practices were collected by developers. And yes, we want to keep current developers, but specially we want current developers follow proper behavior when breaking things. --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
6: PMC Head Concept, 1) Changing Release Strategy 1.1 states: "Trunk becomes experimental". This is why developers contribute also unstable and untested things to trunk. This rule has not been revoked (to my knowledge). The proposal here is to somewhat provide a process that enables "stabilization phases" without breaking this rule. Proposed process should enable to balance progress and stabilization in a reasonable way.
- If we allow to mix experimental things with important bug fixes on the same repository then we'll end in the dependency problem (we have had this problem in current trunk several times). Probably I like better the Tony's proposal below to enforce bug fixing on release, but I also see some developers are asking for a previous peer review, so trunk is acting as the intermediary. New questions arise, how can we enforce developers to commit bug fixes in release? how can we enforce to not commit bug fixes on trunk in a way that can have dependency problems with things in development? what if a developer have a bug fix but it's not sure and want a previous peer review (I see people are using trunk to ask for such process). --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
7:
a) If there is only one developer for a branch, he can work on his local repository. A global repository should not serve as developer backup. If the developer wants to contribute something, he can commit to trunk (with already mentioned rules). If he need support from others, there eventually will be another developer, so we have two maintainers for a new branch.
- Desirable, let's see if it's feasible. --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
b) Maintainers must be different, since they wear different hats: Release maintainer is concerned with stability and preparation of new release. Trunk maintainer is concerned with new features and their integration into trunk. These goal are not mutually exclusive, but - as we currently see - there is potential for conflict.
- I disagree on this, it will open conflicts where there are not at this moment, ANY developer MUST be concerned about quality. --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
c) PMC must not act as police. PMC should be steward to community and provide guidance and advice for development. Furthermore, PMC should mediate conflicts and enable conflict resolution between parties. PMC must not be party in such conflicts. In case someone wants to contribute to the project, he might consider to better take role as developer and not of PMC.
I do not like the idea of bannig people just when something breaks. Beforhand there should be some kind of coaching/advice. Ojnly if problems remain, actions should be considered.
- Some statements here are not fair with the role of PMC these six months, PMC has provided full guidance, advice, coaching, PMC have asked kindly for fixes, etc. Banning people is not because breaking things, is mostly because of refusing to fix, and refusing to follow PMC guidance and rules. Also there is a problem when PMC cannot enforce rules on trunk, but PMC can ban people from trunk, so for disruptive people PMC doesn't have the power to revert, but has the power to ban, I think that must be fixed, so PMC can revert, and banning people is the last resort (at this moment is the only resort). --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
jmpiloq
Comments from Tony Snook (tspc)
1,2 - The Release Strategy was developed after several meetings by volunteers in the PMC Release Group. Anyone who wished to join this group were encouraged to do so. Now they have decided on a strategy, I don't see why it suddenly needs to be changed. What is the point of these people giving their time to discuss and make decisions, if we simply ignore them.
5 - It has been my experience that the PMC Head has been lenient with regard to enforcing the Release Commit Rules. He understands that it will take time for developers to become fully compliant with all the rules. But that does not make the rules wrong, they should be what all developers strive to comply with. He will usually suggest a course of action to rectify a problem and it is only when this is ignored that he steps in and has to take action.
7 - I can't remember how many times people have volunteered to be trunk maintainer, but somehow this has not been followed up with action.
One suggestion I have is that we try again to have all bug fixing done in the release branch, as this is a more logical approach.
Tony Snook
- Tony, I agree with all of your statements here. --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
Link in the developer page
added working procedure in the developer page [1].
- I don't think a page in progress (duplicating content of others approved) must be linked as official --CarlosRuiz_globalqss 17:46, 1 July 2010 (UTC)
- I have created a Template:Draft_proposal for use on documents of this nature. The text used has mainly come from a similar template used in WikiPedia: [2]. It may also be a good idea to include links to the official policy. --Tony 04:49, 4 July 2010 (UTC)
