I've brought this up before, but seeing as one of the core maintainers lives in my office, I thought I'd bring it up again. I believe we should up the level of responsibility of our main core community. I believe each module / the MAINTAINERS.txt should have at least two maintainers attached to it. Officially. An example being search module. Right now, it's the "scary code that Steven figured out how to work right". Luckily, Doug Green has been diving in and working out some patches as well. Let's put Steven and Doug listed as maintainers -- they both now have the search.module queue to be responsible for. The same goes for the rest of core modules, or basically anything with a "component" listed in the Drupal project. This does NOT change commit privileges or process: we have a limited set of core committers who must do the final once over when something goes RTBC. But ideally...RTBC should be that. What do you think? Any volunteers for specific parts? -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On 8/2/07, Boris Mann <boris@bryght.com> wrote:
This does NOT change commit privileges or process: we have a limited set of core committers who must do the final once over when something goes RTBC. But ideally...RTBC should be that.
What do you think? Any volunteers for specific parts?
I'll volunteer to look after upload.module. I'd love to be able to consider the time I've spent puzzling over it as "training" rather than "wasted" ;)
On Aug 2, 2007, at 3:11 PM, Boris Mann wrote:
I believe each module / the MAINTAINERS.txt should have at least two maintainers attached to it. Officially. ... What do you think? Any volunteers for specific parts?
Lovely idea. If you look at MAINTAINERS.txt, you'll see that myself and Earl are already listed as the co-maintainers for update.module. ;) -Derek (dww) p.s. And yes, we both have a bookmark for the issue queue for our core module... ;) http://drupal.org/project/issues/drupal?components=update.module
Derek Wright wrote:
On Aug 2, 2007, at 3:11 PM, Boris Mann wrote:
I believe each module / the MAINTAINERS.txt should have at least two maintainers attached to it. Officially. ... What do you think? Any volunteers for specific parts?
Lovely idea. If you look at MAINTAINERS.txt, you'll see that myself and Earl are already listed as the co-maintainers for update.module. ;)
-Derek (dww)
p.s. And yes, we both have a bookmark for the issue queue for our core module... ;) http://drupal.org/project/issues/drupal?components=update.module
I've also been looking at similar bookmark for D6 theme issues (though not as regularly as perhaps I ought). I may as well make this official. Cause, y'know, more responsibility. Or something. =)
After a certain mammoth patch, I could imagine being listed for the book module... -Peter On 8/2/07, Boris Mann <boris@bryght.com> wrote:
I've brought this up before, but seeing as one of the core maintainers lives in my office, I thought I'd bring it up again.
I believe we should up the level of responsibility of our main core community.
I believe each module / the MAINTAINERS.txt should have at least two maintainers attached to it. Officially.
An example being search module. Right now, it's the "scary code that Steven figured out how to work right". Luckily, Doug Green has been diving in and working out some patches as well. Let's put Steven and Doug listed as maintainers -- they both now have the search.module queue to be responsible for.
The same goes for the rest of core modules, or basically anything with a "component" listed in the Drupal project.
This does NOT change commit privileges or process: we have a limited set of core committers who must do the final once over when something goes RTBC. But ideally...RTBC should be that.
What do you think? Any volunteers for specific parts?
-- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On 8/2/07, Peter Wolanin <pwolanin@gmail.com> wrote:
After a certain mammoth patch, I could imagine being listed for the book module...
And you and chx get blame....err...praise...for menu, as well. Thanks to folks that are responding. Obviously we need buy in from the big D. And...I think the ideal number is 2 "main" devs with 1 alternate, at minimum. The alternate might be a padawan in training (go test this patch!) or might just be a third interested party. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
Well Karoly is already listed as the menu system maintainer... -Peter On 8/2/07, Boris Mann <boris@bryght.com> wrote:
On 8/2/07, Peter Wolanin <pwolanin@gmail.com> wrote:
After a certain mammoth patch, I could imagine being listed for the book module...
And you and chx get blame....err...praise...for menu, as well.
Thanks to folks that are responding. Obviously we need buy in from the big D.
And...I think the ideal number is 2 "main" devs with 1 alternate, at minimum. The alternate might be a padawan in training (go test this patch!) or might just be a third interested party.
-- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On 8/2/07, Peter Wolanin <pwolanin@gmail.com> wrote:
Well Karoly is already listed as the menu system maintainer...
And he needs a buddy. MAINTAINERS.txt is out of date, and needs to actually reflect maintainership. I don't know what process is needed. Bookmarking the issue queue is a good start. Asking person X to review is a good start. Other suggestions? Or do we just wait for Europe to wake up? -- Boris
On Aug 2, 2007, at 4:20 PM, Boris Mann wrote:
Obviously we need buy in from the big D.
Big D already bought in to this concept when I asked him about Earl and myself co-maintaining update.module weeks ago. Consider it decided. On Aug 2, 2007, at 4:34 PM, Boris Mann wrote:
And he needs a buddy. MAINTAINERS.txt is out of date, and needs to actually reflect maintainership.
Agreed.
I don't know what process is needed.
We just need to assemble the updated list of maintainers (g.d.o wiki?) and then turn that into a single core patch. Or, different maintainers could file their own patches to add themselves in a single d.o core issue and skip the unified patch and g.d.o wiki. I don't really care, either way, but it seems like it's less work for the core maintainers to sort all of this out without bothering them, and submit a unified patch for the D6 maintainers.txt file.
Other suggestions? Or do we just wait for Europe to wake up?
Those lazy Europeans, always sleeping aren't they? ;) Cheers, -Derek (dww)
Other suggestions? Or do we just wait for Europe to wake up?
Those lazy Europeans, always sleeping aren't they? ;)
For some time (let's hope not much) I am still European but I am not sleeping. Whether I am lazy is another topic :D On the other hand, having two people around is a good idea but even better would be clearly outlining what does it entail to be a (co-)maintainer...
On Thursday 02 August 2007, Karoly Negyesi wrote:
On the other hand, having two people around is a good idea but even better would be clearly outlining what does it entail to be a (co-)maintainer...
I highly agree with that statement, before I volunteer myself for anything. :-) (I suspect I'll fit the bill for the database system in Drupal 7, but not sure if I want to submit myself now.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Aug 2, 2007, at 10:01 PM, Larry Garfield wrote:
On Thursday 02 August 2007, Karoly Negyesi wrote:
On the other hand, having two people around is a good idea but even better would be clearly outlining what does it entail to be a (co-) maintainer...
I highly agree with that statement, before I volunteer myself for anything. :-) (I suspect I'll fit the bill for the database system in Drupal 7, but not sure if I want to submit myself now.)
Amen. walkah and I have chatted about this several times as well, and I think a strong case can be made that a core maintainer is *NOT* necessarily the person writing all the patches and code for a particular portion of Drupal. Rather, a core maintainer (and their buddy) should be primarily responsible for maintaining architectural knowledge and working with other developers to mentor and 'sanity check' patches and improvements. When we have portions of core that only one developer understands well, it's a bad thing. Steven, a few months ago, commented in IRC that he would not write a particular search-related patch, because no one else understood the mechanics of the requested improvement. That was a wise move: It is *more important* for multiple people to grok a change and understand its architectural impact than for any specific change to make it into core, no matter how cool or needed that change is. That, in turn, helps relieve some of the pressure on the maintainers to 'keep the patches flowing' when the most valuable knowledge they bring to the table is architectural understanding. --Jeff
On 8/2/07, Jeff Eaton <jeff@viapositiva.net> wrote:
On Aug 2, 2007, at 10:01 PM, Larry Garfield wrote:
On Thursday 02 August 2007, Karoly Negyesi wrote:
On the other hand, having two people around is a good idea but even better would be clearly outlining what does it entail to be a (co-) maintainer...
I highly agree with that statement, before I volunteer myself for anything. :-) (I suspect I'll fit the bill for the database system in Drupal 7, but not sure if I want to submit myself now.)
* Bookmark the issue queue * Be up to date on your particular queue, and keep it to a dull roar * raise a cry for alarm / marshall the trips to implement changes and/or look at important stuff that is being proposed * do a first pass on patches / features / bugs etc. -- delegate, deal with, or defer * help push the battle plan for your portion of core and how it interacts with major API changes and the current cycle of development Basically, it's much like maintaining a contrib module, except more coordination. And a higher bar for what gets in.
walkah and I have chatted about this several times as well, and I think a strong case can be made that a core maintainer is *NOT* necessarily the person writing all the patches and code for a particular portion of Drupal.
Well. Actually, unless we get twice the number of people sign up...I kind of expect the bulk of work to be done by ~2 people. Or at least, massage the patches that do show up. The best maintainers will delegate most of this to folks in the queue that are interested.
Rather, a core maintainer (and their buddy) should be primarily responsible for maintaining architectural knowledge and working with other developers to mentor and 'sanity check' patches and improvements. When we have portions of core that only one developer understands well, it's a bad thing.
Steven, a few months ago, commented in IRC that he would not write a particular search-related patch, because no one else understood the mechanics of the requested improvement.
And some more discussions with Steven to truly grok the danger of this is in part what made me speak up again.
That was a wise move: It is *more important* for multiple people to grok a change and understand its architectural impact than for any specific change to make it into core, no matter how cool or needed that change is.
That, in turn, helps relieve some of the pressure on the maintainers to 'keep the patches flowing' when the most valuable knowledge they bring to the table is architectural understanding.
Padawan learners: earn your stripes by wicked pissah feedback on the code you're working on. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On Aug 2, 2007, at 10:48 PM, Boris Mann wrote:
walkah and I have chatted about this several times as well, and I think a strong case can be made that a core maintainer is *NOT* necessarily the person writing all the patches and code for a particular portion of Drupal.
Well. Actually, unless we get twice the number of people sign up...I kind of expect the bulk of work to be done by ~2 people. Or at least, massage the patches that do show up.
The best maintainers will delegate most of this to folks in the queue that are interested.
Yep. I don't mean to say that more skilled coders will magically appear to fix issues if maintainers stop writing code. It was more a thought about what we should view as our ideal to strive towards. With FormAPI, for example, chx and I are still likely to handle the majority of crazy funky bug hunting. There's a growing number of people, though, who are getting more and more familiar with its internals and are knowledgeable enough to tackle the complex patches. I like to think that my primary responsibility is to help make sure the API is accessible to other developers, and to make sure that folks interested in diving deeper get the help they need to grok the architecture. Long term, that will pay off more than any one killer feature. --Jeff
On 8/2/07 6:11 PM, Boris Mann wrote:
I've brought this up before, but seeing as one of the core maintainers lives in my office, I thought I'd bring it up again.
I believe we should up the level of responsibility of our main core community.
I've been having this exact discussion with several people informally and "off list" lately - Steven probably highest amongst those as he's probably the most frequent victim of it not being clearly established..
I believe each module / the MAINTAINERS.txt should have at least two maintainers attached to it. Officially.
I think MAINTAINERS.txt only gets us so far ('cause most people don't read it) - but I think your metaphor is more appropriate. At the very least it would be a good first step. Expanding the 'core team' by domain expertise makes the most sense to me for sure. <snip>
The same goes for the rest of core modules, or basically anything with a "component" listed in the Drupal project.
Yep, I've even suggested to dww that component "owners" would be a great feature for project module - bugzilla / trac /etc all have this concept.
This does NOT change commit privileges or process: we have a limited set of core committers who must do the final once over when something goes RTBC. But ideally...RTBC should be that.
I think solving the RTBC meaning *really* RTBC is a good short-term win... longer term, MAINTAINERS may actually do commits as well, but I agree short term it's not necessary. The Mozilla project uses something sort of like this with "module owners" and there are lots of other examples ... it makes sense.
What do you think? Any volunteers for specific parts?
Yeah, I'm definitely +1 for pursuing it... and of the people I've discussed it with nobody has screamed or thrown things at me for it, so maybe it's got legs. As for volunteering, I'm happily there for blogapi , looks like i'm not "officially" for OpenID yet - but count me in there as well. And then of course there's image handling for D7 ... muhahahahahhahahah er. ya. Thanks for getting the ball rolling, bmann. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
The MAINTAINER.txt just makes explicit what is already in place (trust network). Having two maintainers for one component is perfectly OK. If you consider yourself to be a maintainer or co- maintainer of a particular component, just add yourself to MAINTAINER.txt and submit a patch. If that matches my internal trust model, I'd be happy to commit such patch and to make this more explicit/official. And if all (newly added) maintainers could take responsibility and help fix bugs so we can get Drupal 6 out of the door, that would be lovely. Three weeks ago you guys were complaining that there were too many issues marked as RTBC. Well, now is my time to complain about the fact that there aren't nearly enough issues marked as RTBC. I'll try not to be as vocal about it though. ;) There are three things we should be doing: 1. Fixing bugs in D6 2. Fixing Drupal.org performance 3. Porting modules to D6 Things we should _consider_ to stop doing: 1. Adding features to Drupal 5 projects This might be a little optimistic, but let's aim for a release party at DrupalCon Barcelona? With the help of Gabor and Steven, I hope to roll a first Drupal 6 beta on August 15 (12 days from now). -- Dries Buytaert :: http://www.buytaert.net/
Hmmm, well there are at least three D6 major menu bugs/problems to be fixed up, so I'll try to submit patches this weekend for 2, and the other belongs to chx. Any volunteers to help? -Peter On 8/3/07, Dries Buytaert <dries.buytaert@gmail.com> wrote:
The MAINTAINER.txt just makes explicit what is already in place (trust network). Having two maintainers for one component is perfectly OK. If you consider yourself to be a maintainer or co- maintainer of a particular component, just add yourself to MAINTAINER.txt and submit a patch. If that matches my internal trust model, I'd be happy to commit such patch and to make this more explicit/official.
And if all (newly added) maintainers could take responsibility and help fix bugs so we can get Drupal 6 out of the door, that would be lovely. Three weeks ago you guys were complaining that there were too many issues marked as RTBC. Well, now is my time to complain about the fact that there aren't nearly enough issues marked as RTBC. I'll try not to be as vocal about it though. ;)
There are three things we should be doing:
1. Fixing bugs in D6 2. Fixing Drupal.org performance 3. Porting modules to D6
Things we should _consider_ to stop doing: 1. Adding features to Drupal 5 projects
This might be a little optimistic, but let's aim for a release party at DrupalCon Barcelona? With the help of Gabor and Steven, I hope to roll a first Drupal 6 beta on August 15 (12 days from now).
-- Dries Buytaert :: http://www.buytaert.net/
Boris Mann wrote:
An example being search module. Right now, it's the "scary code that Steven figured out how to work right". Luckily, Doug Green has been diving in and working out some patches as well. Let's put Steven and Doug listed as maintainers -- they both now have the search.module queue to be responsible for.
If Steven agrees, count me in... -- Doug Green douggreen@douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention...
On 8/3/07, Doug Green <douggreen@douggreenconsulting.com> wrote:
Boris Mann wrote:
An example being search module. Right now, it's the "scary code that Steven figured out how to work right". Luckily, Doug Green has been diving in and working out some patches as well. Let's put Steven and Doug listed as maintainers -- they both now have the search.module queue to be responsible for.
If Steven agrees, count me in...
Technically, there is no "agreeing" per se (I guess Dries / the community will veto if someone steps up who has yet to do anything). If you stand up and say you will be the maintainer, it's like agreeing to be a contrib co-maintainer...without the power to actually commit :P I've started revamping the MAINTAINERS list. See http://groups.drupal.org/node/5434 -- Boris
participants (11)
-
andrew morton -
Boris Mann -
Derek Wright -
Doug Green -
Dries Buytaert -
Earl Miles -
James Walker -
Jeff Eaton -
Karoly Negyesi -
Larry Garfield -
Peter Wolanin