<br><br><div class="gmail_quote">On Fri, May 30, 2008 at 4:40 AM, Derek Wright <<a href="mailto:drupal@dwwright.net">drupal@dwwright.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
On May 22, 2008, at 1:33 PM, Darrel O'Pry wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
it's a statement that code and process is easier to change than people and my conviction that processes should adhere to people not the other way around<br>
</blockquote>
<br>
Then I should give up and we should go back to the jungle where contrib is a vast wasteland of unversioned goo. That's what project* and the <a href="http://drupal.org" target="_blank">drupal.org</a> contrib repository should return to if the code/process should adhere to people instead of the other way around. No thanks. ;)</blockquote>
<div><br>I think you're completely wrong here. It was by request and popular demand from both contrib authors and end users that the current release system was built. Otherwise the community would not have ponied up the money for the work to be done.<br>
<br>I just think the system should give developers such as myself more freedom in versioning our modules. Unlike the rest of the world that are writing modules that are only dependent on core.... I'm writing modules that are dependent on other Contrib modules, and I would like to be able to reflect that in my versioning. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If anything, the last ~1.5 years have shown that the process is still too flexible, and there should be more ways that it forces the people to adhere to sane, consistent behavior, not less. For example:<br>
<br>
#252473: Prevent people from putting "-dev" in CVS tag names [1]</blockquote><div><br>only becuase -dev is reserved by the release system for a predetermined release name. The bug only exists because of an enforced naming system.<br>
<br><constructive criticism>The -dev extra is still a little limiting. a timestamp would almost be better. I personally feel users who want to follow head will be using CVS, and those who don't knwo how to use CVS but want to test are using -dev.tar.gz. A timestamp would be a solid indicator as to which -dev release they're using since it is a moving target.</contructive criticism><br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
and perhaps even:<br>
<br>
#90968: enforce sequential release tags in xcvs-taginfo [2]</blockquote><div> </div><div>There was no bug behind this. It's just your opinion of how releases should be numbered. Personally each release I work toward has a set of goals to be accomplished for that release... There is always the possibility that I will do two releases worth of work and release... now is it fair to require me to alter my internal documentation because *you* think releases should be sequential and I overshot my target?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Not to mention disasters like:<br>
<br>
#198278: Prevent bogus branches by checking at commit time, too [3]</blockquote><div>Yep validation for the enforced naming structure should be universal if we're going to have enforced naming conventions, but is un related to the general concept of a more flexible release system. <br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
that resulted in messes that still aren't completely resolved:<br>
#152832: cleanup faulty branches [4]</blockquote><div><br>I think I have a few of those... and wouldn't it be wonderful if I could fix them myself. At the very least the ability to edit my release names/delete releases to change mis tagged things, etc would be nice... I mean I am maintainer over my project right? I am the one who is *expected* to bear the support load right? <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Of course, if everyone were careful, and already comfortable with sane release management, it'd be a different story. Sadly, the d.o infrastructure mostly has to cater to the lowest common denominator in terms of ability and experience. I've been trying to balance the needs of experienced, clueful people like you and me, with the reality of 100s of brand new contributors and their propensity to break things, not to mention everyone's aversion to reading documentation. ;) I won't claim I've always made all the right decisions and choices, but I believe I've done a pretty good job of it. If you have disagreements, concrete help and constructive criticism would be much more appreciated than adding to the chorus of empty complaints ("it's offensive that update_status went into core"), even if you're already a valuable contributor in other ways.</blockquote>
<div><br>I think, for the community, there is more advantage in teaching people sane release management and helping people become comfortable with it than there is enforcing it. Knowledge and skill propogation is an awesome thing.<br>
<br>It also allows more freedom for unexpected use cases, and the ability for individuals to experiment with their own release managment within constraints that won't just break the packaging system. Seeking what works best for them and their workflow. An issue queue can be motivation enough to make someone research best practices.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
p.s. "Them's fightin' words ;)" was meant as a joke and a pop-culture reference, nothing more.</blockquote><div><br> p.s. I know I'm still giving you a hard time and telling you to put a multicolored LED wall on your bikeshed.<br>
</div></div><br>