[development] New version control policies/system?(was: Consolidating duplicate contrib modules for D7)
Daniel F. Kudwien
news at unleashedmind.com
Wed Dec 9 02:03:53 UTC 2009
> Wait - no, you're right.. The universe is static. Change is
> impossible, thus reconsidering established practices leads nowhere.
No, it means that a project's organization grew with its own growth.
> > If someone is interested in following this practice for their own
> > module they can do so
> ..how does this improve the issue of 'maintainers' not
> efficiently cooperating? Where is the incentive to combat
> feature duplication?
It means that every maintainer is free to let any contributor help out and
freely commit to a project, in case the contributor has CVS access. This is
a very common practice on drupal.org already, so I really have to wonder how
much you are involved in contrib development.
> > simply add anyone to the list of maintainers that asks for it.
> Wow, that really sounds so much more like a feasible, well
> thought through strategic plan...
> Heck what if someone is qualified to _hack_ the code but -
> not qualified to (co-)'maintain' a module?
How can you maintain hacks? You cannot. And you won't ever be able to
maintain it if anyone can commit arbitrary hacks to your project. After
all, you are maintaining a project so that other users can use it without
experiencing bugs.
If you are able to hack code but not able to maintain, then file a patch.
If you are not able to maintain, then don't expect your code to work for
others.
> > My personal sense is that when I see more than 3-4 maintainers on a
> > project I get concerned that it is probably not architecturally
> > consistent and likely poorly maintained (the "everyone thought it
> > should be done, anyone can do it, nobody did it" problem).
> This is not about raising the numbers of module maintainers,
> but about abolishing their sovereignty over code - is this
> FREE software, or just open? Why do we put code under the GPL
> in the first place?
You are free to file a patch, if you can code. If you can maintain, then
you are free to apply as co-maintainer. If you can maintain and you think
that someone else cannot, then you are free to request to take over project
ownership. If you can maintain and you think that someone else cannot, and
taking over a project is not possible, then you are free to create a new
project, given that you know Drupal's APIs (and are therefore granted CVS
access).
Thus, you have plenty of freedom. The Drupal project and community builds
on collaboration to innovate and build a better product for users.
If your code is not for users, then why do you want to hack something and
contribute in the first place?
> > but another apt way to describe an
> > environment where anyone can do whatever they please is a
> > "commons" as
> > in http://en.wikipedia.org/wiki/Tragedy_of_the_commons
> even with good intent i see no way how this could apply to
> the drupal open source project. Code is one of the very few
> things that grows in size if you share it ;)
Then you obviously didn't see Drupal modules that are not properly
maintained and contain countless of hacks. Are those useful for anyone?
No.
> Alright, everybody and his mother is busy doing other stuff.
> Why don't we put up a huge call for action on the drupal.org
> frontpage? Theoretically, the pure migration of the
> repositories should not take more than a few hours, right? If
> we as the drupal collective don't put it upfront the priority
> list, obviously it will be completed once hell is (at least
> half) frozen X-P
This, next to your other replies, makes me believe that you neither want to
contribute nor collaborate. Without contribution, it won't ever happen.
You may want to re-consider your position. Or not.
More information about the development
mailing list