[development] Slow down with the official releases of contrib already, ok? ; )

[Darrel O'Pry]

On Fri, May 30, 2008 at 4:40 AM, Derek Wright <drupal at dwwright.net> wrote:

>
> On May 22, 2008, at 1:33 PM, Darrel O'Pry wrote:
>
>  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
>>
>
> 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
> drupal.org contrib repository should return to if the code/process should
> adhere to people instead of the other way around.  No thanks. ;)


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.

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.


> 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:
>
> #252473: Prevent people from putting "-dev" in CVS tag names [1]


only becuase  -dev is reserved by the release system for a predetermined
release name. The bug only exists because of an enforced naming system.

<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>


> and perhaps even:
>
> #90968: enforce sequential release tags in xcvs-taginfo [2]


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?


> Not to mention disasters like:
>
> #198278: Prevent bogus branches by checking at commit time, too [3]

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.


> that resulted in messes that still aren't completely resolved:
> #152832: cleanup faulty branches [4]


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?


> 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.


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.

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.

p.s. "Them's fightin' words ;)" was meant as a joke and a pop-culture
> reference, nothing more.


p.s. I know I'm still giving you a hard time and telling you to put a
multicolored LED wall on your bikeshed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080530/dceeb3d1/attachment-0001.htm