Somewhat of a joke / serious comment -- but if the KDE development process is so good -- why does Gnome exist?<div><br></div><div>I think some of your ideas Marcel have merit but you're ignoring that a) as with everything, there's no silver bullet and b) you're overestimating the benefit of your ideas and underestimating the cost in developer time to implement the changes and in education to retrain everyone on how drupal development happens.</div>
<div><br></div><div>I think switching to a DCVS-type development would be a great benefit but it's not going to happen overnight and it's not going to magically make every problem go away.</div><div><br clear="all">
--Kyle Mathews<br><br><a href="http://kyle.mathews2000.com/blog">kyle.mathews2000.com/blog</a><br><a href="http://twitter.com/kylemathews">http://twitter.com/kylemathews</a><br>
<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 4:58 PM, Marcel Partap <span dir="ltr"><<a href="mailto:mpartap@gmx.net">mpartap@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> > How exactly do you define 'release to the public'? Commiting<br>
> > code to a development branch used only by developers? Or<br>
> > releasing ready-made quality-inspected module packages?<br>
> Almost all projects have development snapshot releases that are repackaged<br>
> every 12 hours. How much more is "public"?<br>
</div>Well in that sense, as good as every line of open source software is 'public'. To me 'release to the public' implies a push operation by the developer - post a release statement with download link in some form.<br>
<div class="im"><br>
> > > * The maintainer still really should be the only one<br>
> > creating release<br>
> > > tags,<br>
> > Why?<br>
> Because the maintainer is "guilty" for the bugs that users experience,<br>
> regardless of whether its caused by own code, code by co-maintainers, or<br>
> flawed code introduced in patches by contributors.<br>
</div>Guilt? What's that thinking supposed to be good for.. Personally i much prefer the concept of responsibility.<br>
Just for example: in the more open KDE development paradigm, for mnst participants, committing to the code means also committing to the quality and success of the code. It actually works(tm).<br>
<div class="im"><br>
> Really, it seems you have not maintained any project at all.<br>
</div>That's correct. I wanted to, but didn't yet get around to.<br>
<div class="im"><br>
> > > and for that matter is the only one that can edit the project<br>
> > > page and create the release nodes.<br>
> > mmh.. What is the key characteristic of the internet project<br>
> > with the hugest growth rate in the last decade? (*)<br>
><br>
> You forgot that there is an armada of content moderators in your scenario.<br>
> This armada does not exist, especially not regarding the skill-level.<br>
</div>So how do we loose qualified drupal developers once we take out the only-maintainer-writable? And if we don't, what is the issue here.<br>
<div class="im"><br>
> That's why we have modules, and that's why we promote a proper separation<br>
> between APIs. That's why we have module dependencies. There is no one<br>
> who<br>
> understands all. But we also don't need someone like that, because it's<br>
> sufficient to understand and focus on a particular sub-system or module.<br>
</div>How is anyone forced to come up with greater code insight by merely removing write restrictions on the repository?<br>
<div class="im"><br>
> > > Note that core is the extreme of this, with massive<br>
> > > interdependence and 2 committers.<br>
> > Yes, but there are more than two people in the project<br>
> > capable of grokking every commit that goes into drupal core.<br>
> > These two 'just' mostly do the (highly critical!) job of<br>
> > judging code readiness (relying heavily of course on opinions<br>
> > voiced on the report thread), plucking the cherries from that<br>
> > big colourful issue queue tree ;==)<br>
><br>
> Do those other people need to commit? No.<br>
</div>Noone _needs_ to - but certain restrictions on who can are also unnecessary.. It's FREE software, is it not?<br>
<div class="im"><br>
><br>
> <a href="http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-" target="_blank">http://www.unleashedmind.com/en/blog/sun/improving-drupal-cores-development-</a><br>
> workflow<br>
</div>IIUC this post is about CORE development, for which i see NO CHANGE NECESSARY. Core development works just fine the way it is.<br>
BTW, regarding this core-contrib distinction: i would also count views module to the core area, as it is a vital module but only really understood by very few (so it should be protected from inexperienced eager beavers ;) - and scheduled for inclusion in D8 anyway.<br>
<div class="im"><br>
> > > * If anything I'd say this would discourage people from<br>
> > > contributing a<br>
> > > module, since other people breaking their code is now a<br>
> > > hassle they have to deal with.<br>
> > Breaking *whose* code? Is this still free software - or just<br>
> > freeware hosted on a common platform?<br>
> Breaking the code that users want to use.<br>
</div>In a development branch? How awful. None of the other FOSS projects do that.. unstable branches are just named this way to scare people away, not because the code is actually unstable..<br>
???<br>
Release versions should definitely be stable and consistent - but for experimental branches, code breakage is to be expected. Just like with everything that has 6.x-dev in it.<br>
You didn't actually respond to my main argument btw: the code is ours _as a community_, not the private property of the maintainers - else it would just be freeware, not free software.<br>
<div class="im"><br>
<br>
> > > If the maintainer is not doing their job, there is a process<br>
> > > for replacing them.<br>
> > Bureaucreacy (how tf is this spelled **g) to solve problems<br>
> > that wouldn't exist without it, we need more of it.<br>
> Why would you want to contribute to a project, if you can't establish a<br>
> trust-relationship to the project maintainer?<br>
</div>Because i actually and exclusively care about the technical superiority of the code?<br>
<div class="im">> Because, if you can establish one, there's little that hinders you from<br>
> becoming a co-maintainer, or have your patches committed quickly.<br>
</div>Yes of course. What if it _does not_ work this way. Bugger.<br>
<div class="im"><br>
> Again, we want to encourage contribution and collaboration. Not<br>
> discourage it.<br>
</div>How am i proposing to discourage that, quite the contrary..<br>
wow this is getting tedious. I really hoped for some more support, but it seems there is only fear from current maintainers that something will be taken away from them. We will probably have the same duplicate modules problem with D7 as with D6, instead of stemming the united effort of consolidating and merging the functionality of thousands of modules into a couple of frameworks and some hundred submodules.<br>
<br>
regards,<br>
<font color="#888888">marcel.<br>
</font><div><div></div><div class="h5">--<br>
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!<br>
Jetzt freischalten unter <a href="http://portal.gmx.net/de/go/maxdome01" target="_blank">http://portal.gmx.net/de/go/maxdome01</a><br>
</div></div></blockquote></div><br></div>