This group is a place for developers who are interested in how Drupal manages issue tracking, software releases, integration with CVS and other revision control systems, and related areas of functionality. Currently, the project module and casetracker module are the main modules in this space.
Suggestions for improving the d.o issue queue (especially for core)
This page is a place to gather suggestions to improve the drupal.org issue queue (provided by the Project issue tracking module), especially as relates to the core issue queue (by far the largest and most active queue on the site). Please add to the list, or edit items to provide a link to the corresponding issue (feature request, whatever) in the project issue queue.
Note: Requests to add or rename issue status values belong in the drupal.org webmaster issue queue (component == 'Site organization') since those are just admin settings on d.o, not hard-coded into project_issue.module.
Read more
Upgrade Drupal.org to Drupal 7 Sprint!
The week of April 23 - April 27, the Drupal Association is sponsoring a sprint, hosted by the Oregon State University Open Source Lab, to upgrade Drupal.org from Drupal 6 to Drupal 7!
The sprint will be mainly focused on the following areas, and the following attendees will be there:
Read moreDrupal.org Office Hours
Come to Drupal.org office hours to share what you're working on and help us come up with the weekly drupal.org hit list!
Stop by #drupal-infrastructure from 11am to 12pm Pacific Time (18:00 - 19:00 UTC).
Read more
Issue following is now live on Drupal.org!
Yay -- another victory for the Prairie Initiative and improving Drupal.org!
Drupal.org front page news:
Stop subscribing, start following
See also:
The history of how we killed "subscribe" comments on Drupal.org
People interested in this might also be interested in:
Expand "follow" functionality on Drupal.org
And while I'm dropping links, for anyone in town for BADCamp, don't forget to checkout:
Read more
CMS Ninja Training in Downtown NYC
FREE LAMP CMS Ninja Themer and Developer Training...
Are You Tired of wondering how the Drupal CMS REALLY works?
This is hands-on expert training that has already jump started MANY in just a few hours.
First session is always FREE!
The emphasis is on expert team dev tools and workflows, hands-on. There are NO prerequisites.
!! SIGN UP HERE: http://drupal.meetup.com/9
CMS Team Ninja Themer Training: Themers are responsible for the look and feel of a CMS site.
**Think "Interior Decorator".
Ninja Themer Skills We Train Hands-On...
Read moreProject metrics for drupal.org redesign
One of the big goals of the drupal.org redesign is to make it easier for end users to find the right modules for the site they're trying to build. With over 5,000 contributed modules, many of them providing similar functionality, it can be extremely difficult to choose. One method is to try to assess the "health" of the module, by how actively it's maintained, used, supported, etc.
One approach to gauging health is posted at Project ratings and reviews for drupal.org redesign. While that proposal deals with subjective factors, this post addresses objective facts about a module that can be computed and displayed for all projects hosted on drupal.org. While no single metric can tell you what module to use, and some knowledge will be required to make the best use of this data, it's important to make these statistics more readily available on drupal.org to empower users to make better decisions.
The redesign prototype for project pages includes the introduction of a sparkline showing the "Activity" for each project. The details of this activity chart weren't specified at a technical level during the design phase, but the spirit of the design is that they wanted more ways to visualize the health of a project. As we're implementing the redesign, we've been empowered to provide as many charts containing specific data we think will best help end users make sense of what's going on with a project. Read on for our specific proposal, including what metrics to compute, and some ideas on how those are going to be visualized on the new drupal.org
Read moreProject ratings and reviews for drupal.org redesign
One of the major new features proposed in the redesign site prototype for making it easier to find the right modules for end users is the introduction of Project ratings and reviews. This post is a proposal for how we're planning to implement these features as part of the redesign. If there's sufficient traction for this proposal, we could actually roll this out independently of the redesign theme launch itself.
Read moreA detailed description of the workflows after we implemented phase 3
Last updated by greg.1.anderson on Wed, 2011-03-16 17:56
This is a summary and detailed implementation plan distilled of the orginal discussion over at http://groups.drupal.org/node/50438
While the orginal plan was written by CorniI, I expect this wiki page to be adjusted as we further clarify technical points. I also used content from the people contributing at the orginal wiki page.
This will then serve as a TODO list for the implementation of phase 3 of the migration to git.
In general, please fix any wording/grammar/whatever mistakes you find in here.
Read more
Revamping Branch/Tag naming conventions - our ONE chance for a clean switch!
The branch and tag naming conventions are kinda old and crusty. Thanks to a feature of the migration script we'll be using to move to git, we have the option of changing our branch and tag conventions, and renaming all of the old crusty ones at the same time. That means we could actually do a clean migration to a new naming convention - and that we'll probably never, EVER have another opportunity to do so.
Read morePersonal sandboxes/repos/branches for issues for git
We all agree that we want some sort of github-like fork/clone to participate in a project with git.
This means, that somehow, we want to be able that, for a given project and a given issue all users which have submitted a ssh key can contribute.
What we haven't decided on is how to do that, there are several ways.
One repository per project, per user
Each user gets a clone of the main repo hosted on d.o where she can do whatever she wants to.
Read morepro-Mercurial points for shifting Drupal.org
Mercurial (or popularly, hg) is a DVCS written in Python. It is known for its ease of use, without compromising a lot of power.
See parent wiki page Action items for moving Drupal.org off of CVS for more generic information.
<
ul>
pro-Bazaar points for shifting Drupal.org
Bazaar is DVCS written in Python, known for its very easy setup and good portability across all major operating systems.
See parent wiki page Action items for moving Drupal.org off of CVS for more generic information.
(start writing points already!)
-
Bazaar homepage: http://bazaar.canonical.com/en/
-
Bazaar is the way to go if Drupal wants to lower barriers to contribution- Git has a steeper learning curve.
- Bazaar might be an easier migration for cvs/svn users
- Bazaar is easy.
pro-Git points for shifting Drupal.org
Git is an advanced DVCS in C, that was initially written by Linus Torvalds. It is known for its amazing performance and superior flexibility.
For details and starters, see http://git-scm.org
See parent wiki page Action items for moving Drupal.org off of CVS for more generic information.
Tools for the server
- List on kernel wiki
- Gitosis: http://eagain.net/gitweb/?p=gitosis.git
Evaluation discussion for how to move Drupal.org off of CVS
Conclusion
Git has been selected as our new VCS!
http://groups.drupal.org/node/48818?page=2#comment-133893
http://sf2010.drupal.org/conference/sessions/exodus-leading-drupal-out-cvs
http://groups.drupal.org/drupal-org-git-migration-team
Debate archived below:
We actually had quite a productive IRC discussion tonight (no, that is shockingly not an oxymoron!) about the general migration to distributed development, the community fragmentation that it causes, and how the tools on drupal.org might be improved as a way to combat this.
Read morePackaged distributions now deployed on drupal.org!
The testing phase is over... 3281d Consulting is extremely pleased to announce that the new distribution packaging system is now deployed on drupal.org. The announcement on the front page of drupal.org contains lots of details about how the system looks for end users of Drupal distributions, including lots of nice UI changes to project pages and release nodes.
If you maintain an installation profile on drupal.org please read the How to package a profile on drupal.org handbook page. It's really not that hard, but there are some very important things you need to read and understand to make use of the new system. Support requests and "bug reports" from people who just didn't read the handbook page won't be well received. ;) Oh, and speaking of issues, if you find one, please search the packaged install profiles tag before submitting a new one.
Exciting times -- go forth, yonder profile maintainers, and make Drupal more usable!
Thanks!
-Derek
Full packaging for installation profiles/distributions on drupal.org ready for testing
In case anyone missed the announcements in Planet Drupal, we're going to have fully packaged installation profiles/distributions on drupal.org. Yay! ;) The system goes live Monday night, 6pm PST. Anyone who's maintaining an installation profile project on drupal.org is strongly encouraged to help test the new system. Full details here:
http://3281d.com/2009/11/28/packaged-install-profiles-ready-for-testing
Thanks!
-Derek
Issues to consider for multiple project branches
One part of my GSoC is to add support (of some sort) to VersionControl API for having multiple branches within a project (like a drupal.org project) with different user permissions. The idea is to allow a more DVCS-like workflow, where people can work independently on their own branch and then request an admin user to pull their changes into the master repository. I won't be starting this for a few weeks, but I wanted to get a discussion going about what it should look like.
Read moreHow to handle Git (or other VCS) allowed branch/tag names?
I'm working on the Git hooks (specifically the 'update' hook right now) and am trying to figure out what sorts of things we would want in a pre-commit (or pre-push, in the case of DVCSs) hook.
What I have now
For now, I have only been checking whether the user attempting to push has an account with the given repository. Combined with the "admin must approve accounts" setting on repositories, this seems good enough to be useful.
Read more
Agile Process Planning Poker Module
Planning poker is fun, but if you're on a distributed team how do you play?
There are online tools to do this, but I'd like a simple way to do this in Drupal. Some thoughts:
- If all your issues are stored in Drupal then you could play poker with a node that consists of a nodereference field and a number field and then display the results of those node submissions. This feels like a sledgehammer solution.
Git and Drupal Core workflow
This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts:
