On May 8, 2009, at 12:22 PM, Zach Welch wrote:
Breaking the trunk only causes problems because _everyone_ is using itinstead of regular releases. That is the maintainers fault to be sure; this would not be a huge problem if everyone had their attention focusedon a release branch.
[snip]I've argued this a number of times. Right after I did the 0.1.0 release, I wanted to get together a list of goals for 0.2.0. Instead, rampant change was made to trunk. Some of the items that went into trunk were improvements that appeared to have minimal risk, but others were questionable and risky. There were frequently large commits that blended multiple sets of changes which made it nearly impossible to backport anything to the 0.1 branch making a 0.1.1 unrealistic. Once a list for 0.2.0 was agreed upon, it was basically ignored. For example, the Cortex-A8 support was something we wanted for 0.2.0, but the in_handler changes were never mentioned. As it stands, sorting this out for a 0.2.0 would be a full time job.
To be clear, I'm not blaming anyone specifically. This is a failing of the community and maintainers to set and follow policies on patch approval and release engineering. Even some of the work I've done has increased the effort required to made a stable 0.2.0.
Ideally, we would have frequent enough stable releases that our typical users aren't living on trunk. Having the package maintainers snapshot our repo should be a clear sign that something is wrong.
In theory, the trunk _is_ an experimental branch to some extent. This community's reliance on it helped show that Øyvind surpassed the de facto limit to the community's tolerance for mainline breakage. Arguably, this is not his problem alone. The community must shoulderpart of the blame for failing to make regular branches of the trunk forthe explicit purpose of maintaining stability... and for failing to provide failsafe processes for handling experimental patches.
Agreed. When I have some time to get my thoughts in order, I plan to reply to your proposal thread.
In this respect, I am starting to worry about the patches that I havepending... are they too invasive? Should I post them first? If I haveto post every patch for others to consider, then why do I have commit access to the repository (well, for my proposed rule above, to start). Clear lines must be drawn, but these did not exist in any form.
Yup. The lack of these clear lines has created nothing but antimocity for anyone attempt to use or develop on the project.
I tell ya': I would be on my way out the door if I had gotten the net response that Øyvind received today, after only three weeks on the job and given my initial reservations. During this all, I think he has acted very professionally. I can see why Dick and Jeff left, and I am feeling bad about the part that I played in it. Contributing to a project without meaningful processes is too much like gambling.
Sadly the people trying to define and enforce meaningful processes tend to be given similar treatment.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
