Re: [Proposal] Development process and a stable trunk
Thorsten Scherler wrote: On Sun, 2005-08-28 at 14:19 +1000, David Crossley wrote: Thorsten Scherler wrote: Before you read this reply, please read again my original reply. Did you read it, ok then go ahead and please be not offended that your name may not be mentioned here or in the other thread but you actually contributed to views in any form. That is not my intention. I was focusing on code for views and the common danger of ignoring threads. First of all, you will need to try very hard to be able to offend me. You were not. :) Cheers for telling me this, that is a relief. I am lucky that you are know me quite well because you help me from the beginning. That is true, but the point I was trying to make about offending people is that many people do not know us quite so well. We have to be careful not to offend newcomers. Did you see the recent thread on the infra@ list about netiquette? It asked if there is a problem here in Apache. The only conclusion I drew from it was that too many of us have formed a little group within the community who know each other well and so cutting remarks are taken in context of that relationship. These remarks often alienate newcomers who do not have the background of the older community members. I only raised the issue to keep us aware of the potential problem. I think we all know the intention was not to discredit anyone. But even in your response you said something about nobody else has committed code. That is also not true, nor is it important since discussion is an equally valued part of the community. We need to be careful about statements that remove the recognition of the community from people who contribute. There's no need for you to respond, I know you well enough to see it as an oversifght. I am raising it as a broader community issue, and I know you have the thick skin to cope with any percieved criticism - we all know that we write poor emails sometimes, this is a community awareness broadcast. Interestingly, when I wrote the original mail it wasn't David or myself that I thought may be offended, but some other newer members of the community who have also contributed to forrest:views - seems my own mail was a problem in the community sense :-(( .. I agree whole-heartedly with your warning about ignoring threads and at the same time i am saying that we need to allow people to particpate in some things and not others. Yes, I agree but we need to define core components and this core components should be understood and enhanceable from many active PMC member. I really do not want to see that we depend on individuals, we have do depend on the community. That is as well why I think we should rename whiteboard to incubation. All components that need more community support should go here. If we want to follow Stephano's dreamlist we have to be very clear on the community part of components. I have no problem renaming the whiteboard. There is sense in your proposal. I would recomend starting a new thread saying you are going to do it unless someone objects. ... If other people helped more with applying patches, then people like me would be relieved and could help more with views development. There is one patch sitting there from a new developer. Who is going to commit it before i get compelled to jump in? You are right. That is really a thing that I need working on. Anyway, like always said, I see views different and by getting into views I understood that this will change the general parts of the project. That is why I keep on asking for getting the views integration done. Just do it (in a branch), I proposed removal of views from whiteboard immediately after the 0.7 release. You refused, wanting it to stay in whitebaord, you said it wasn't ready. I had the time then, but not now. I took that time to build a site using views. That site is now in production - in my opinion views is stable enough, it is only implementation details that will change. Don't wait for me (speaking personally) since I am more keen to simplify our sitemaps using the locationmap, I think this will make forrest:views integration easier. However, I don't know when I will be able to do this, other commitments are in the way right now. Let me give you an example. The xhtml2 change will force us to rewrite the same pipes that we need to change for the views core integration! So will the locationmap work :-( Another point is the integration of the locationmap. Right now it is set up but there have to be touched a lot of pipes to really use it, again that are nearly the same like for views. Knowing this made me ask everybody to get into views. I'm sorry, it just doesn't owrk that way. Most of us are not here as a hobby or a play thing. Most of us use Forrest as part of our jobs. THat means we have to focus on the parts that are important to our job function. Get views into trunk (you have my +1 for a long time
Re: [Proposal] Development process and a stable trunk
Thanks everybody for taking the time to respond and giving me a change to re-think and refine my own thoughts on these issues. Here are some comments for a start: - Ignoring of threads (or developments) I'm sorry to say this but I'm simply not able to read everything that's on this list all the time. And even though this might have to do with going kayaking too often in my case :-), I think that with growing volume of project and list this will happen to most of us sooner or later. For me prioritizing stuff in this list is a necessity rather than a choice. And at the moment I can never tell the relevance of a thread to Forrest as a hole. I know that it would be nice if all of us could follow all the threads, but honestly, is that realistic? Also: A lot of people might join the list without the interest or the capacity to follow all our discussion from the start. Following new developments from when a merger is proposed gives them a good interface to cutting-edge forrest development without the bloodloss :-). - When to branch After considering your responses I realize that I need to refine the criteria for branching: Changes should happen in a branch when they - change (not fix) to output - require additional or different input - change (not add) existing configuration options The reason behind this demand is, that all these changes require users and developers to adjust their applications or their coding work in progress. So in order to do that efficiently they should have well defined, finalized and properly documented changes to deal with. In addition I would suggest branching also - when the internal workings of a module are altered in a major way. The reason for this being that anybody also working on, extending or even debugging such a module does not get in the middle of somebody else's major change or has to guesswork about the function of some undocumented new piece of code. - Vote on merging branches I have no problem with the lazy consensus model her. What is more important to me is that fact that at least some developers not involved in the implementation should have looked at (not just 'have had a chance to look at') and tried the new functionality. Now I know that this is hard because you have to get somebody to do this and perhaps even wait for them to do it. But on the other hand I expect this to have a couple of useful side effects: - Documentation and value of the new developed functionality have to be properly balanced or nobody will do the testing. - The time waiting for a tester is often useful to rethink and refine the solution and perhaps even improve on the docs. -- Ferdinand Soethe
Re: [Proposal] Development process and a stable trunk
Ross Gardler wrote: ... We need to decide how to use Jira to create this ToDo list and then we need to start actually using it. I'd concentrate on the actually doing stuff part (not directed to you Ross, it's a general remark). After having been on vacation, I now see hundreds of mails with lots of words and very little content, and even ignoring complete threads like I'm already doing is proving to be not enough. If the signal to noise ratio will not improve, we will have more problems with newcomers, and I will be forced to unsubscribe for lack of time. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Proposal] Development process and a stable trunk
Ferdinand Soethe wrote: Thanks everybody for taking the time to respond and giving me a change to re-think and refine my own thoughts on these issues. Here are some comments for a start: - Ignoring of threads (or developments) I'm sorry to say this but I'm simply not able to read everything that's on this list all the time. And even though this might have to do with going kayaking too often in my case :-), I think that with growing volume of project and list this will happen to most of us sooner or later. For me prioritizing stuff in this list is a necessity rather than a choice. And at the moment I can never tell the relevance of a thread to Forrest as a hole. I know that it would be nice if all of us could follow all the threads, but honestly, is that realistic? Also: A lot of people might join the list without the interest or the capacity to follow all our discussion from the start. Following new developments from when a merger is proposed gives them a good interface to cutting-edge forrest development without the bloodloss :-). I agree with everything said and feel that this is what the conclusion of the thread has been. It is the respopnsbility of the PMC to read *all* commits, not *all* mails. We should not *ignore* threads though. I tend to read the first post in a thread, if it is a priority for me I read all subsequent posts otherwise I skin read the subsequent posts. I also have filters set up on my mail client that will detect if someone types my name. So if someone says I wonder what Ross thinks or Ross, how would this fit into plugins or something like that my client flags the message for me. In addition, as you point out well worded subjects are important. I'm not sure about prefixing with a branch name since a discussion about something in a branch is also a discussion about what will end up in core. So it is no less relevant just because it is in a branch. - When to branch After considering your responses I realize that I need to refine the criteria for branching: Changes should happen in a branch when they - change (not fix) to output - require additional or different input - change (not add) existing configuration option In earlier threads (linked to in my prevoius mail) we discussed criteria for branching. I think the conclusion was that it should be up to the individual dev do decide. It isn't really possible to create a set of rules - nothing wrong with examples like those above (and below) though. The reason behind this demand is, that all these changes require users and developers to adjust their applications or their coding work in progress. So in order to do that efficiently they should have well defined, finalized and properly documented changes to deal with. +1, I think Tim expressed this as something like a realeasable trunk does not requrie users to jump through any hoops. In addition I would suggest branching also - when the internal workings of a module are altered in a major way. The reason for this being that anybody also working on, extending or even debugging such a module does not get in the middle of somebody else's major change or has to guesswork about the function of some undocumented new piece of code. - Vote on merging branches I have no problem with the lazy consensus model her. What is more important to me is that fact that at least some developers not involved in the implementation should have looked at (not just 'have had a chance to look at') and tried the new functionality. Since all PMC members have a responsability for reading *all* commits, then (in theory) all developers will ahve watched what was going on in the branch anyeay. There should be no need for a separate review cycle before merge. In my opinion the docs + tests we discussed are more important. Now I know that this is hard because you have to get somebody to do this and perhaps even wait for them to do it. But on the other hand I expect this to have a couple of useful side effects: - Documentation and value of the new developed functionality have to be properly balanced or nobody will do the testing. - The time waiting for a tester is often useful to rethink and refine the solution and perhaps even improve on the docs. Here you are proposing a formal test process before merging. I'm not sure how I feel about this. Speaking personally, I don't have the time to test *all* of other peopls code, they could wait for me for a long time, this will cause problems. I prefer to trust that they have tested it sufficiently before commiting and merging. (longer term I would prefer a proper test suite in Forrest, but that is a whole different thing and should not delay progress on your proposal). Ross
Re: [Proposal] Development process and a stable trunk
On Sun, 2005-08-28 at 14:19 +1000, David Crossley wrote: Thorsten Scherler wrote: Before you read this reply, please read again my original reply. Did you read it, ok then go ahead and please be not offended that your name may not be mentioned here or in the other thread but you actually contributed to views in any form. That is not my intention. I was focusing on code for views and the common danger of ignoring threads. First of all, you will need to try very hard to be able to offend me. You were not. :) Cheers for telling me this, that is a relief. I am lucky that you are know me quite well because you help me from the beginning. I was trying to use myself as an example to show various things: that everyone has their own itches to scratch, silence does not mean disinterest, that people are actually reading your commits and emails but not necessarily contributing, people are busy doing other things, we each have something that we wish others would work more on, there are some fundamental issues that need to be cleared, etc. I understand, believe me I really do. The thread was as well only an example of myself. I try to use myself as an example so that there is no risk of other people getting offended or unnecessarily defensive. That backfired today :-) ;-) I agree whole-heartedly with your warning about ignoring threads and at the same time i am saying that we need to allow people to particpate in some things and not others. Yes, I agree but we need to define core components and this core components should be understood and enhanceable from many active PMC member. I really do not want to see that we depend on individuals, we have do depend on the community. That is as well why I think we should rename whiteboard to incubation. All components that need more community support should go here. If we want to follow Stephano's dreamlist we have to be very clear on the community part of components. By the way, thanks for daring to use views as a case to discuss these important issues about how this small yet diverse project can operate. :) You are welcome. More below ... Ross Gardler wrote: David Crossley wrote: Thorsten Scherler wrote: All PMC members should feel responsible for *all* issues of forrest. We should do whatever we can manage and try to not ignore anything. My background is certainly views where I am the position of *not* ignoring this threads but sometimes it seems to me that the rest is doing it. Well i certainly am not. I try to read everything and only respond if i think that i need to. Even started my next project to use views, so expect more development soon. I trust you to get on and do the best you can and i will try to help when i can manage it. Please don't take silence to mean that nobody cares. That is not true. I should have written *seems*! You did already. I was trying to dispel your impression that nobody is interested. I should have prefaced my comments to explicitly say that i was supporting and exploring the issues, and that there was no offence. Cheers. I know and it was nothing against somebody en special and least against you or Ross! See your response about the comments, I was not aware of it myself and you pointed us in the right direction. Now if you would have kindly ignored the thread, then we would try to find the problem in views. Thx for being an example for *not* ignoring threads. Yes, I think these comments are true for most devs. We all have limited time and assume that lazy consensus is in operation most of the time. To be honest, I am a little offended that my input, when it comes, is not recognised (actually I'm not, I know that is not what you meant but it supports my point, others, who do not know your style, may well be offended by comments like those above). I wrote: The answer is that Diwaker and Cyriaque are the only ones beside me that contributed to the code base. I was actually thinking about commits or patches that where made to the view code base. I should have written committed. I always consider input as very welcome and you are right that this are contributions as well. I am awe-fully sorry if I have offended somebody with my comments that was not my intention. English is not my first language and my choice of words seems to cause many confusion lately. I am sorry for that. No need. Even in one's native language these issues are hard to deal with. Important issues often are. Start from the point of trust. We know that you are not offending anyone. Feel free to say whatever you need. jeje Are you sure ;-) thx Anyway right now I wish more input with code examples and was talking about that. If somebody recommend some changes to sources then this is best done with code examples (aka
Re: [Proposal] Development process and a stable trunk
Ross Gardler wrote: Ferdinand Soethe wrote: What I'd like to see in the future: 1 Adjust our development process so that the current development version (I think this is called 'trunk') is always releasable, stable and _well documented_ (meaning complete and correct, not well written or suitable for a dummy user). 2 Develop all major changes and new features in separate branches that will only be merged back into trunk when they are stable and well documented (not talking refined documentation but good enough that a technical writer could work with it) and a good number of committers not involved in the process have reviewed and tested them. Both 1 and 2 are already agreed in principle, we just have to action it by creating the infrastructure and processes, see end of this mail for links. We did discuss this earlier and seemed to be in agreement. I know that documentation is a good thing, but i don't see how we can measure it enough to be able to deny a merge. Perhaps if there is at least some docs then merge is okay. 3 Discuss and vote one merging each branch back into trunk. -1. We only need to discuss major contributions. You will see in the above linked thread that we are talking about using branches for *all* work that may break existing functionality, however votes should only be taken on major functionality. Instead of a vote what should happen is that someone announces they are going to merge into trunk unless someone objects (i.e. lazy consensus) I agree, but they also need to allow time for the world to turn a bit so that that we all have time to raise concerns. 4 Create a new release whenever such a merger has taken place so that new functionalities become quickly available to new users and can be stress tested in a production environment without too many changes to consider as a source for potential problems. -1 for the same reason as above, some branches will be for minor changes in functionality. However, we have already agreed, in principle, to do more frequent releases. I believe the intent of your suggestion here is aligned with that so I agree with the intent. This would also make testing of new releases a lot more focussed. I would like to go a step further and say we do not merge branches until we have automated tests for the new features and all existing tests pass. Tests would be good, but as yet we don't have a good enough testing framework to be so rigorous. 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch so that people not working on that issue can safely ignore it. +1 Don't use the ignore word. I agree with Thorsten that that can be damaging to community. Wouldn't a well-chosen subject title suffice. -David
Re: [Proposal] Development process and a stable trunk
On 8/26/05, Ross Gardler [EMAIL PROTECTED] wrote: Ferdinand Soethe wrote: I have an uncomfortable gut feeling with the current status of our pre-release version and I'd like your feedback on these concerns and my suggestions to change our process. My concerns with the current situation: - in the last few month a number of exciting major projects (location maps, views, i18n, change of cocoon ...)and a number of smaller ones have been developed (which is good!) - most of them have not been finished to the point of being releasable and (so it seems to me) will not be for considerable time so it seems like we won't be able to release quickly without a major clean-up effort (which I consider bad). - the work-in-progress-state and its (perfectly normal) unfinished documentation make it very hard for people to understand the development version or work with it at any point in time or understand the implications and side effects of each new development. What I'd like to see in the future: 1 Adjust our development process so that the current development version (I think this is called 'trunk') is always releasable, stable and _well documented_ (meaning complete and correct, not well written or suitable for a dummy user). We've talked about this before and last time the only thing I had heartburn with was always releasable trunk as it implies an Always Branch system and I think that's overly rigid and runs counter to our community goals. A reasonably stable trunk is a good goal. Well documented to the extent possible - if something is still under heavy development then time shouldn't be wasted documenting yet (beyond that which would allow other devs to check it out). Heavy development in the trunk? Yes, if it's not causing the trunk to be unstable, then yes. 2 Develop all major changes and new features in separate branches that will only be merged back into trunk when they are stable and well documented (not talking refined documentation but good enough that a technical writer could work with it) and a good number of committers not involved in the process have reviewed and tested them. Develop all major changes and new features *that may make the trunk unstable* in separate branches maybe. As written, I think this would lead to fracturing in a couple ways. 1) devs wouldn't check-out all the other branches and new stuff would be sole-developed even more so than some things are now; 2) bleeding-edge users won't get into checking out multiple branches to checkout new functionality (i.e. no patches). Both 1 and 2 are already agreed in principle, we just have to action it by creating the infrastructure and processes, see end of this mail for links. I think we agreed to these goals (more or less): 1) a stable trunk (ie. no hoop-jumping to build and run). 2) a branch for anything that would violate goal #1 3) each branch in #2 should be independent features (so that each can merge separately) My take on what's being suggested goes well-beyond this but maybe I'm reading too much into it. 3 Discuss and vote one merging each branch back into trunk. -1. We only need to discuss major contributions. You will see in the above linked thread that we are talking about using branches for *all* work that may break existing functionality, however votes should only be taken on major functionality. Instead of a vote what should happen is that someone announces they are going to merge into trunk unless someone objects (i.e. lazy consensus) 4 Create a new release whenever such a merger has taken place so that new functionalities become quickly available to new users and can be stress tested in a production environment without too many changes to consider as a source for potential problems. -1 for the same reason as above, some branches will be for minor changes in functionality. However, we have already agreed, in principle, to do more frequent releases. I believe the intent of your suggestion here is aligned with that so I agree with the intent. This would also make testing of new releases a lot more focussed. I would like to go a step further and say we do not merge branches until we have automated tests for the new features and all existing tests pass. I don't think we're mature enough for that. At least, I've not seen a robust enough test harness around for it. 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch so that people not working on that issue can safely ignore it. +1 Encouraging such on the project would lead, in my opinion, to a fractured community. People naturally tend to prioritize email based on the subject line, but supporting that through branch prefixes or the like would lead to several mini-projects. Heck, people might even set up email filters to only look at their branch -- not good. I think instead we need folks
Re: [Proposal] Development process and a stable trunk
David Crossley wrote: Thorsten Scherler wrote: Ferdinand Soethe wrote: 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch +1 so that people not working on that issue can safely ignore it. -1 All PMC members should feel responsible for *all* issues of forrest. We should do whatever we can manage and try to not ignore anything. My background is certainly views where I am the position of *not* ignoring this threads but sometimes it seems to me that the rest is doing it. Well i certainly am not. I try to read everything and only respond if i think that i need to. Even started my next project to use views, so expect more development soon. I trust you to get on and do the best you can and i will try to help when i can manage it. Please don't take silence to mean that nobody cares. That is not true. Yes, I think these comments are true for most devs. We all have limited time and assume that lazy consensus is in operation most of the time. To be honest, I am a little offended that my input, when it comes, is not recognised (actually I'm not, I know that is not what you meant but it supports my point, others, who do not know your style, may well be offended by comments like those above). Most of my time is being taken up with general issues for the Forrest project, so i don't often have the time to help. I wish that other people would help more with that stuff, applying the patches, guiding the new developers. +1000 (and a big thank you to David) That cannot keep on in the future. Let me give you an example why not. Imaging I have a car accident and dead (very drastic example I have to admit but it is possible). Now all forrest devs are kindly ignoring the [views] thread, what is happening then? We could say the same about things like the catalog entity resolver. I wonder who else besides me understands it or enhances it. Or plugins half way through the 0.7 dev, or the locationmap, or i18n or any one of the features within Forrest. Thorsten, you really must understand that you are only considering your own baby - it *is* important, but no more important than any of the other features being introduced. The level of input you get on views is comparable to the level of input on other peoples babies. As David said, silence means we trust you to do a good job, we speak up when we see a problem or an easier way of doing things, otherwise we let you get on with it (and in most cases use it with pleasure). There other things that i want to solve with views before diving in. Like the unfinished thread about Defining Views Terminology. +1000 - there was a proposal some time ago (written by someone not currently credited by you as doing any work for views). Your response to that was I'm working on a proposal, but so far nothing has been forthcoming and we have not had your input on the second thread that David started (also not credited with doing any work on views). [Note, I'm not pointing fingers with these bracketed comments, just trying to further illustrate my point of potential offense given by these statements] And i think that moving the core to XHTML2 is more important at this stage, so i will put my spare energy there. Don't see that as ignoring views as i expect that will help. Actually, I thought forrest:views in core were going to be the first version of Forrest wusing XHTML2. So your work on XHTML2 *is* work on helping forrest:views move to core. Ross
Re: [Proposal] Development process and a stable trunk
David Crossley wrote: Ross Gardler wrote: Ferdinand Soethe wrote: What I'd like to see in the future: 1 Adjust our development process so that the current development version (I think this is called 'trunk') is always releasable, stable and _well documented_ (meaning complete and correct, not well written or suitable for a dummy user). 2 Develop all major changes and new features in separate branches that will only be merged back into trunk when they are stable and well documented (not talking refined documentation but good enough that a technical writer could work with it) and a good number of committers not involved in the process have reviewed and tested them. Both 1 and 2 are already agreed in principle, we just have to action it by creating the infrastructure and processes, see end of this mail for links. We did discuss this earlier and seemed to be in agreement. I know that documentation is a good thing, but i don't see how we can measure it enough to be able to deny a merge. Perhaps if there is at least some docs then merge is okay. +1 - not enough docs could be one reason why someone would object to a mere (see below) 3 Discuss and vote one merging each branch back into trunk. -1. We only need to discuss major contributions. You will see in the above linked thread that we are talking about using branches for *all* work that may break existing functionality, however votes should only be taken on major functionality. Instead of a vote what should happen is that someone announces they are going to merge into trunk unless someone objects (i.e. lazy consensus) I agree, but they also need to allow time for the world to turn a bit so that that we all have time to raise concerns. +1 - 3 complete revolutions of the planet is the usual on other projects. ... This would also make testing of new releases a lot more focussed. I would like to go a step further and say we do not merge branches until we have automated tests for the new features and all existing tests pass. Tests would be good, but as yet we don't have a good enough testing framework to be so rigorous. True, so we need to create one. The absence of one should not prevent us from moving forwards with Ferdinands proposal, but it should be considered an important addition to the process. 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch so that people not working on that issue can safely ignore it. +1 Don't use the ignore word. I agree with Thorsten that that can be damaging to community. +1 - I had interpreted ignore in the context of lazy consensu, I agree nothing should be ignored in the sense of no notice is taken. Wouldn't a well-chosen subject title suffice. +1 Ross
Re: [Proposal] Development process and a stable trunk
Tim Williams wrote: On 8/26/05, Ross Gardler [EMAIL PROTECTED] wrote: Ferdinand Soethe wrote: I have an uncomfortable gut feeling with the current status of our pre-release version and I'd like your feedback on these concerns and my suggestions to change our process. My concerns with the current situation: - in the last few month a number of exciting major projects (location maps, views, i18n, change of cocoon ...)and a number of smaller ones have been developed (which is good!) - most of them have not been finished to the point of being releasable and (so it seems to me) will not be for considerable time so it seems like we won't be able to release quickly without a major clean-up effort (which I consider bad). - the work-in-progress-state and its (perfectly normal) unfinished documentation make it very hard for people to understand the development version or work with it at any point in time or understand the implications and side effects of each new development. What I'd like to see in the future: 1 Adjust our development process so that the current development version (I think this is called 'trunk') is always releasable, stable and _well documented_ (meaning complete and correct, not well written or suitable for a dummy user). We've talked about this before and last time the only thing I had heartburn with was always releasable trunk as it implies an Always Branch system and I think that's overly rigid and runs counter to our community goals. A reasonably stable trunk is a good goal. Well documented to the extent possible - if something is still under heavy development then time shouldn't be wasted documenting yet (beyond that which would allow other devs to check it out). Heavy development in the trunk? Yes, if it's not causing the trunk to be unstable, then yes. +1, my recollection of the previous discussion was that a branch is used for new functionality or major refactoring. My recollection of always releasable is that Forrest devs are using it in production environments. This implies that there may be one or two hidden bugs but in the main it is releasable. In addition always releasable should mean that all tests are past (when we have them) 2 Develop all major changes and new features in separate branches that will only be merged back into trunk when they are stable and well documented (not talking refined documentation but good enough that a technical writer could work with it) and a good number of committers not involved in the process have reviewed and tested them. Develop all major changes and new features *that may make the trunk unstable* in separate branches maybe. As written, I think this would lead to fracturing in a couple ways. 1) devs wouldn't check-out all the other branches and new stuff would be sole-developed even more so than some things are now; 2) bleeding-edge users won't get into checking out multiple branches to checkout new functionality (i.e. no patches). The reality of most work is that it starts of as a one person operation until it becomes usable, occasionally someone else comes along (as you did with Loationmaps). SVN does not force users to checkout complete branches. They simply run a switch command and that's it. this is a very fast operation in most cases. Having said that, I agree with your concerns. It's difficult to decide when not to branch, often a simple change becomes something much more major. Both 1 and 2 are already agreed in principle, we just have to action it by creating the infrastructure and processes, see end of this mail for links. I think we agreed to these goals (more or less): 1) a stable trunk (ie. no hoop-jumping to build and run). 2) a branch for anything that would violate goal #1 3) each branch in #2 should be independent features (so that each can merge separately) My take on what's being suggested goes well-beyond this but maybe I'm reading too much into it. My take, is as you define it. Who knows exactly what Ferdinand meant (I'm sure he'll tell us if it is different). What we need to do is document it, this thread and the others I linked to in a previous reply go a long way to providing this documentation. We just need someone to have the time to pull it all together. ... This would also make testing of new releases a lot more focussed. I would like to go a step further and say we do not merge branches until we have automated tests for the new features and all existing tests pass. I don't think we're mature enough for that. At least, I've not seen a robust enough test harness around for it. I don't understand how we can not be mature enough. In agile programming you write the tests *before* you write the code. We are a long way from that, but I don't see why we can't try and catch up a bit. At the very least we should insist that the minimal testing we do have is passed (David as set up an instance of Forrest on our zone, we need to make use of this for
Re: Help with general project issues [was: Re: [Proposal] Development process and a stable trunk
Tim Williams wrote: On 8/27/05, David Crossley [EMAIL PROTECTED] wrote: Most of my time is being taken up with general issues for the Forrest project, so i don't often have the time to help. I wish that other people would help more with that stuff, applying the patches, guiding the new developers. What's that stuff? I'm happy to help beyond just development work if I know what the issues are. Basically, most of what David does is the stuff that the rest of us largely ignore but is absolutely vital to the survival of the project ;-) Here are a few thinks that I think David may be referring to (I am sure he'll add some more to the list): - maintenance of the published site - configuration of a testing environment on our Zone - maintenance of Jira - issues linked to discussions - links between issues - proofing documentation - ensuring user feedback is reflected in our documentation - checking license files are correct and complete - applying bug fixes - fixing bugs (rather than creating new features) - running build test before committing changes - ... Ross
Re: [Proposal] Development process and a stable trunk
Before you read this reply, please read again my original reply. Did you read it, ok then go ahead and please be not offended that your name may not be mentioned here or in the other thread but you actually contributed to views in any form. That is not my intention. I was focusing on code for views and the common danger of ignoring threads. On Sat, 2005-08-27 at 14:51 +0100, Ross Gardler wrote: David Crossley wrote: Thorsten Scherler wrote: Ferdinand Soethe wrote: 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch +1 so that people not working on that issue can safely ignore it. -1 All PMC members should feel responsible for *all* issues of forrest. We should do whatever we can manage and try to not ignore anything. My background is certainly views where I am the position of *not* ignoring this threads but sometimes it seems to me that the rest is doing it. Well i certainly am not. I try to read everything and only respond if i think that i need to. Even started my next project to use views, so expect more development soon. I trust you to get on and do the best you can and i will try to help when i can manage it. Please don't take silence to mean that nobody cares. That is not true. I should have written *seems*! I know and it was nothing against somebody en special and least against you or Ross! See your response about the comments, I was not aware of it myself and you pointed us in the right direction. Now if you would have kindly ignored the thread, then we would try to find the problem in views. Thx for being an example for *not* ignoring threads. Yes, I think these comments are true for most devs. We all have limited time and assume that lazy consensus is in operation most of the time. To be honest, I am a little offended that my input, when it comes, is not recognised (actually I'm not, I know that is not what you meant but it supports my point, others, who do not know your style, may well be offended by comments like those above). I wrote: The answer is that Diwaker and Cyriaque are the only ones beside me that contributed to the code base. I was actually thinking about commits or patches that where made to the view code base. I should have written committed. I always consider input as very welcome and you are right that this are contributions as well. I am awe-fully sorry if I have offended somebody with my comments that was not my intention. English is not my first language and my choice of words seems to cause many confusion lately. I am sorry for that. Anyway right now I wish more input with code examples and was talking about that. If somebody recommend some changes to sources then this is best done with code examples (aka patches) or commits. Diwaker and Cyriaque provided patches that extended the views code base and enhanced the implementation. For example David et. al. as well is committing to the code base regularly, I did not mentioned everyone because I was thinking about patches. Most of my time is being taken up with general issues for the Forrest project, so i don't often have the time to help. I wish that other people would help more with that stuff, applying the patches, guiding the new developers. +1000 (and a big thank you to David) Yes, you, David and Ross, are doing an awesome job. Thanks very much. Sorry, if I offended you, it was not my intention. That cannot keep on in the future. Let me give you an example why not. Imaging I have a car accident and dead (very drastic example I have to admit but it is possible). Now all forrest devs are kindly ignoring the [views] thread, what is happening then? We could say the same about things like the catalog entity resolver. I wonder who else besides me understands it or enhances it. Or plugins half way through the 0.7 dev, or the locationmap, or i18n or any one of the features within Forrest. Thorsten, you really must understand that you are only considering your own baby - it *is* important, but no more important than any of the other features being introduced. No, I actually did not only consider my own baby, that was only an example. Replace [views] and my person with all your mentioned features and they main supporter like Ross and plugins, David and catalog entity resolver,... My point was that we cannot kindly ignore threads that may are not our personal focus. The level of input you get on views is comparable to the level of input on other peoples babies. Yes, you are right. Maybe because it is replacing/extending skins. As David said, silence means we trust you to do a good job, we speak up when we see a problem or an easier way of doing things, otherwise we let you get on with it (and in most cases use it with pleasure). Yes, again you are right. Sometimes I only wish that code example would be a bigger
Re: [Proposal] Development process and a stable trunk
Just to sort of answer one part of this at the moment :- I have an uncomfortable gut feeling with the current status of our pre-release version and I'd like your feedback on these concerns and my suggestions to change our process. My concerns with the current situation: - in the last few month a number of exciting major projects (location maps, views, i18n, change of cocoon ...)and a number of smaller ones have been developed (which is good!) - most of them have not been finished to the point of being releasable and (so it seems to me) will not be for considerable time so it seems like we won't be able to release quickly without a major clean-up effort (which I consider bad). Along with CSS , I am also working on some parts of i18n, mainly to get it working to ensure a site with it enabled is still valid. Apart from that AFAIK it works, only that it is not implemented for the whole site, only parts of it. David has hinted that this will be some time away before the rest of it gets implemented, but the base of it will be there and working and should not get in the way of a release. (I just need the i18n:textpenny to drop/text and I'll have a patch shortly!) Gav...
Re: [Proposal] Development process and a stable trunk
Ferdinand Soethe wrote: I have an uncomfortable gut feeling with the current status of our pre-release version and I'd like your feedback on these concerns and my suggestions to change our process. My concerns with the current situation: - in the last few month a number of exciting major projects (location maps, views, i18n, change of cocoon ...)and a number of smaller ones have been developed (which is good!) - most of them have not been finished to the point of being releasable and (so it seems to me) will not be for considerable time so it seems like we won't be able to release quickly without a major clean-up effort (which I consider bad). - the work-in-progress-state and its (perfectly normal) unfinished documentation make it very hard for people to understand the development version or work with it at any point in time or understand the implications and side effects of each new development. What I'd like to see in the future: 1 Adjust our development process so that the current development version (I think this is called 'trunk') is always releasable, stable and _well documented_ (meaning complete and correct, not well written or suitable for a dummy user). 2 Develop all major changes and new features in separate branches that will only be merged back into trunk when they are stable and well documented (not talking refined documentation but good enough that a technical writer could work with it) and a good number of committers not involved in the process have reviewed and tested them. Both 1 and 2 are already agreed in principle, we just have to action it by creating the infrastructure and processes, see end of this mail for links. 3 Discuss and vote one merging each branch back into trunk. -1. We only need to discuss major contributions. You will see in the above linked thread that we are talking about using branches for *all* work that may break existing functionality, however votes should only be taken on major functionality. Instead of a vote what should happen is that someone announces they are going to merge into trunk unless someone objects (i.e. lazy consensus) 4 Create a new release whenever such a merger has taken place so that new functionalities become quickly available to new users and can be stress tested in a production environment without too many changes to consider as a source for potential problems. -1 for the same reason as above, some branches will be for minor changes in functionality. However, we have already agreed, in principle, to do more frequent releases. I believe the intent of your suggestion here is aligned with that so I agree with the intent. This would also make testing of new releases a lot more focussed. I would like to go a step further and say we do not merge branches until we have automated tests for the new features and all existing tests pass. 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch so that people not working on that issue can safely ignore it. +1 A few weeks ago I started working on summarising the many discussions like this that we have recently had. I have never found the time to finish it, in fact I hardly got started. I'll copy what I have here, I'd encourage someone to take this, put it in SVN and add the other details from the threads linked to in this draft and the additional stuff suggested above. -- --- Pre-draft of Development Process --- -- This proposal is a summary of the following recent threads Project participation and hackability [1] and [2] Using Jira and branches for Project Management [3] I also used Cocoons [4] project management wiki page for inspiration. It is intended to be the starting point not the end game, we should move this into a document (any volunteers?) and keep it up to date as we learn on the job. Some of the things in here will prove to be unworkable, some will be improved. Lets try them and see how it goes. --- Objectives == To define a project management process that will enable Forrest to continue to grow without becoming a totally chaotic environemnt. To create a structure to progect management that is not restricitve to the Open Source development process To define processes that, when followed correctly, will reduce the effort required for Forrest developers to participate effectively, that is, to not overly burden developers will project management tasks To create a single point of reference for accepted best practices within the Forrest development community Background == Forrest is growing rapidly in many directions. We have a far larger developer base than just a few months ago, we have a code base that is expanding in many directions and we have a user base that are applying Forrest to an increasingly diverse range of problems.
Re: [Proposal] Development process and a stable trunk
On Fri, 2005-08-26 at 07:28 +0200, Ferdinand Soethe wrote: 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch +1 so that people not working on that issue can safely ignore it. -1 All PMC members should feel responsible for *all* issues of forrest. My background is certainly views where I am the position of *not* ignoring this threads but sometimes it seems to me that the rest is doing it. That cannot keep on in the future. Let me give you an example why not. Imaging I have a car accident and dead (very drastic example I have to admit but it is possible). Now all forrest devs are kindly ignoring the [views] thread, what is happening then? Luckily there are some other devs that have started using views but developing them? The answer is that Diwaker and Cyriaque are the only ones beside me that contributed to the code base. Still I am the only one that is developing the views core. IMO views will be one of the major reasons for user to use forrest. We need more devs that are helping to develop the core and not people not working on that issue can safely ignore it. salu2 -- Thorsten Scherler Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [Proposal] Development process and a stable trunk
Thorsten Scherler wrote: Ferdinand Soethe wrote: 5 As a supportive measure, clearly mark threads in this list when they deal with a particular branch +1 so that people not working on that issue can safely ignore it. -1 All PMC members should feel responsible for *all* issues of forrest. We should do whatever we can manage and try to not ignore anything. My background is certainly views where I am the position of *not* ignoring this threads but sometimes it seems to me that the rest is doing it. Well i certainly am not. I try to read everything and only respond if i think that i need to. Even started my next project to use views, so expect more development soon. I trust you to get on and do the best you can and i will try to help when i can manage it. Please don't take silence to mean that nobody cares. That is not true. Most of my time is being taken up with general issues for the Forrest project, so i don't often have the time to help. I wish that other people would help more with that stuff, applying the patches, guiding the new developers. That cannot keep on in the future. Let me give you an example why not. Imaging I have a car accident and dead (very drastic example I have to admit but it is possible). Now all forrest devs are kindly ignoring the [views] thread, what is happening then? We could say the same about things like the catalog entity resolver. I wonder who else besides me understands it or enhances it. Luckily there are some other devs that have started using views but developing them? The answer is that Diwaker and Cyriaque are the only ones beside me that contributed to the code base. Still I am the only one that is developing the views core. That happens sometimes. There other things that i want to solve with views before diving in. Like the unfinished thread about Defining Views Terminology. And i think that moving the core to XHTML2 is more important at this stage, so i will put my spare energy there. Don't see that as ignoring views as i expect that will help. IMO views will be one of the major reasons for user to use forrest. We need more devs that are helping to develop the core and not people not working on that issue can safely ignore it. Yes, and that goes for all parts of development. So i agree that nothing can be safely ignored. It sounds like Ferdinand's off-hand comment hit a raw nerve that we know is there. I had a similar one at Cocoon with the entity resolver and with the docs. Please don't get dejected. At least we have two new committers starting to help on views. -David
