Matthew Bishop wrote:
I'm not sure why we would merge changes from head onto an old branch. I could see us making small fixes to the branch and pushing those changes back into head, but not really vice versa.I've worked this problem both ways, one where the codebase is copied into a new repository (perforce-ism) and development continues on both tracks, and the other where the main line is branched and changes in the head are merged into the new version branch.
Again, usually if it's just bug fixes those would be done on the branch directly and then merged back to head. Head would also have new features going into it, so you don't want to take code from that and merge it back to a branch.Branching makes sense when the bug fixes on the head can be reliably merged into the branch over time. If the changes are big, then branching is a pain and merges end up being done by hand rather than through CVS as the code moves around or becomes obsolete.
Scope is large, or at least could be. There's been some discussion of reworking the mailet API, repositories, and probably a lot of other pretty fundamental stuff. Hopefully in the end the changes won't be too significant, but I think it's starting with brainstorming and then will retreat back to what people can actually get time to do.I don't fully understand the scope of changes under discussion for James 3, but it would be simpler to maintain one module and add the changes into the existing codebase, replacing old components with the new hotness (like Serge's mordred/dbcp switch). Not only is it simpler, it helps keep the project grounded in reality, especially as more automated tests comes online in the next few months.
Sure, always a risk, but open source actually excels in this area... people using the released version will report/patch problems on that code.A new repository works well under two conditions: there's good leadership on both modules going forward and there's good team members on both tracks. If the 2.x repository becomes orphaned and everyone is off working on 3.0, there's a risk that fixes and improvements to the 2.x line will not occur and the product will languish while everyone is working on the next big thing.
It's a meritocracy, so if someone wants to work on it, they can. It's very hard to keep a part-time volunteer in a leadership role, i.e., have the community decide on this or that. Best we can do is provide avenues so the people who want near-term stable 2.1.x release can work on that and the people passionate about a longer term release can work there. The two directions are pretty congruous as I would expect most relevant changes in 2.1.x to get pushed into 3.x. Eventually 3.x will need to get this short-term release passion, so 2.x people can move to 3.x and we can get a solid release of 3.x out.So if a new repository is made, it would be wise to make sure that someone takes on the 2.x leadership role to keep fixes and improvements to 2.x coming to maintain product momentum.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
