Issue tracking and software releases

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
This group should probably have more organizers. See documentation on this recommendation.

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.

jpetso's picture

Version Control API iterations

Well, I promised you an update on the API module, so that's what you'll get. Just a short notice beforehand: the CVS backend's database structure is now online and available for everyone's reviewing pleasure. Module functions will be added in a week or two, but before that, I'll get the xcvs-* scripts to fill in the entries for the new database structure. I've also made a (slightly different, but largely similar) SVN version of the .install file, you can find that one attached to this post. (As a Subversion backend module is only an optional deliverable, I'd rather not start a versioncontrol_svn project and its directory in CVS just yet.) So it seems to me that deliverable number three, a finished database schema for the CVS backend, can be marked as done.

Get to the point, dude!

Ok, ok. My remaining problem with the Version Control API was that it lacked a way to consistently deal with tags and branches, and to uniquely identify files and directories even if they are not versioned themselves (which is the case for directories in CVS and other version control systems). So I thought a bit more about how to deal with this, and the outcome is a new building block object for items, in addition to the previously existing ones for repositories and commits.

Read more
jpetso's picture

News on project node integration

Actually, I wanted to write a piece on how the Version Control API is maturing, but I've got to leave here in a few minutes and won't have internet available until tomorrow, so this must wait for now. Instead, a short coverage of the Version Control / Project Node Integration module (versioncontrol_project.module).

Read more
jpetso's picture

Comeback

[disclaimer] I'm writing this update while drupal.org (including g.d.o) is attacked by database-eating gremlins, so I can't currently check back on previous entries. Apologies in advance if I mention something that has already been said before. Yes, I could use the Google cache, but that's kinda tedious. [end of disclaimer]

So, I've been pretty absent for quite some time. After getting my university stuff finished, I found a bit less time for my Summer of Code project than I had expected, moving out from the dorms, packing bags, wrapping up undone stuff, whatever. Last week (June 29th to July 7th) I've been attending aKademy, the KDE conference, as previously announced. Great event, great people, great location (this year it took place in Glasgow, Scotland). You can read lots of coverage on KDE Dot News - start here (you can find me in the group photo) and go left in the navigation at the buttom, the marketing team has been active as never before. I wonder in which ways DrupalCon will be different from aKademy, as in my view the projects and their attitudes already differ fundamentally. Ok, so that's that.

Not having found the time before, I reallocated a few hours from aKademy's hacking sessions to my Summer of Code project. Since the last real update, the RCS API module has changed its name to Version Control API (versioncontrol.module), and the former project_rcs.module is now Version Control / Project Node Integration (versioncontrol_project.module). Both now contain a good amount of API functions for accessing commit data. Even if the implementation is still missing out (which, according to the project proposal, has been planned this way), they are the core of what other modules will use from the API module. (Read more...)

Read more
jpetso's picture

Mercurial findings

So, Mercurial, or "hg" in short. One of the two revision control systems originally written for being the Linux kernel's BitKeeper replacement - in the end, git was chosen for that job, but Mercurial lived on nevertheless. The requirement of being suitable for kernel development implied two features: performance (although git is still a tiny bit faster) and distributed development methodologies. Both are also present in git, and in fact, the two systems are very similar in scope, paradigms and usage patterns.

While git is written in pure C, Mercurial mostly consists of Python code, with only small, critical code paths implemented in C. This has benefits for Mercurial's portability, as can even be observed with other SoC students. git is pretty much focused on just Linux, whereas Mercurial can also be installed more easily on Windows and other Unixes. Not that straightforward graphical tools are yet as mature as the ones that exist for CVS or SVN.

Read more
jpetso's picture

CVS, the veteran workhorse

CVS, or Concurrent Versions System, was the de-facto standard open source version control system for a long time. It came up in the late 80s and grew popular enough to manage the source repositories of virtually all open source projects until only a few years ago (when Subversion started to take over). It's still widely used, including on drupal.org, but hardly deployed on newly created repositories anymore. Development is strictly fixed to a centralized client-server methology, and while distributed version control systems (or Subversion with svk) strive to make a checkout independent from the server, with CVS you're completely dependent on a fast and reliable connection to upstream.

In summary, there's little surprises in this CVS coverage, especially for the resident drupal.org admins. But necessary nevertheless, if only for later reference. Obviously, no new requirements for the API module were found, as the CVS setup on drupal.org together with the Project module is the status quo at the moment.

Read more
jpetso's picture

A peek at Subversion

My project definition says that I still got to document the specifics of SVN and CVS (git has been taken care of). Coming from the KDE camp, I'm already acquainted to Subversion to a certain degree, as the whole huge KDE repository switched from CVS in May 2005. (No one, including the SVN admin, did regret the switch).

Subversion (SVN) came up as a replacement for CVS - motto: "CVS done right" - and incorporates its centralized development methology and its straight-forward workflow, while improving on its weak parts. Compared to CVS, Subversion features good stuff like atomic commits, renaming, serverless diffs, symlink support and version-controlled directories, to name the most popular ones. It fulfills its role as a drop-in replacement brilliantly and has kinda deprecated CVS, at least for newly installed repositories. (That, of course, doesn't stop Linus Torvalds from claiming that centralized development methologies are outright wrong.)

Read more
jpetso's picture

Commit data

There was a quote of someone saying that inexperienced programmers worry about code, while advanced programmers worry about data structures. Don't remember who said that, but personally I find this an excellent analysis.

Let's try to formulate the important questions that need to be answered in order to get the Revision Control API right:

  1. What kinds of functionality do users need from the API?
  2. What kinds of functionality do different revision control systems provide?
  3. How does the data that is delivered to the caller look like?
  4. Which functions are required to deliver the data to the caller?
Read more
jpetso's picture

Git scrutinized

There's a great introduction on git for SVN people like me, which made it twice as easy for me to look into how this thing works. Git only recently released their 1.5 version which is the first one that's supposed to be usable to the masses. (It might not yet be available pre-packaged for your Linux distribution, or available at all if you're running Windows, which could be a small hurdle at the beginning.) After reading the introductory couse and trying it out by myself, I must say I'm hooked.

For those who didn't know, git is the distributed RCS that was created by Linus and the other kernel folks because they needed to get rid of BitKeeper, and as the Linux kernel is a very demanding project both in code size and in patch management, git is quite capable indeed from an efficiency point of view. Currently in use by the Linux kernel itself, X.org, Wine, and One Laptop Per Child, to name a few popular projects.

As promised in my SoC application, here's a short rundown of features that are important to this abstraction layer.

Read more
jpetso's picture

Diving into SoC

So that's that. After having used the past two months for improving filefield and imagefield, it's about time that I get started with my RCS abstraction project. aclight has been as kind as to publish his work and findings in time with the Summer of Code, so that's a good starting point already. His work on the xcvs scripts (...bootstrapping Drupal, yay) benefits my project a lot, and the issues with password storage are good to know of.

In order to come up with a set of good questions that I'll need to research, I had a first shot on the database schema and the overall idea of how this thing should work. I thought it would be a good idea to see what we want to achieve and what we can rely on, before figuring out how to abstract all the stuff that's supposed to be different among the various revision control systems. Bullet points galore.

Read more
aclight's picture

Project tracking and releases using Subversion

Hi Everyone

For the past few months, I've been working on a fork of the cvslog and project* modules to be able to use them with subversion instead of cvs. After consulting with dww, maintainer of these modules, I learned that someone (jpetso) had applied, and by now has received, a Google SoC position for creating an RCS abstraction layer. Eventually, such a layer would presumably make it a little easier to use a version control system other than CVS.

Read more

How to help with the project* modules

The project* collection of modules (Project, Project issue tracking, and CVS integration) is the largest set of code running on drupal.org besides Drupal core. They are the key tools that power all Drupal development, including the Drupal issue queue and Drupal release system. Because of the huge user base, high visibility, complex requirements and feature requests, and size and scope of the existing code base (and issue queues) there is a ton of work to be done. This wiki page is how I (dww, the primary maintainer of project*) will try to communicate the best ways for other people to get involved in helping. One of the ways to help is to improve this list, so please add your own ideas here.

Read more

Proposal: drupal.org testsite install profile

this is an idea i've been thinking about. posting it here so other folks can add to it, provide feedback, etc.

Summary

we could really use an install profile that setup a test site similarly to how drupal.org is configured (especially the project* modules and CVS integration). obviously, it wouldn't have the bluebeach theme, but otherwise, it would look fairly similar to d.o in terms of structure, content, permissions, etc.

this would greatly help people who wanted to reproduce bugs and test patches for the project* family of modules, which is something we desperately need more of.

Read more
jpetso's picture

RCS abstraction for the Project module: preliminary final version

I just uploaded my application to Google's Summer of Code web app, and I can say I'm quite proud of its current state. The application has seen a couple of iterations based on valuable feedback by Adam Light and Derek Wright, both of which are working on RCS stuff for the Project module. Being fed into Google, this means that the Drupal mentors can now place private comments and supporting votes there.

Given that there are a good number of comments on some of the other proposals in this group, I'm still wondering if there is something I can do to spread the word and get more input from the greater public. After all, work on the Project module severely affects the great majority of drupal.org users, and getting rid of CVS as a hard dependency should really be discussed in the wider community. So do communicate your opinions about my application, its benefits for Drupal, its chances to get elected, its shortcomings, challenges, etc. ...I'm listening.

Read more
dww's picture

2 important Project module and drupal.org improving SoC ideas

Myself, Webchick and Killes have come up with two proposals for this year's SoC which involve the drupal.org infrastructure and the project module. Both of which could solve some of the worst drupal.org usability problems, and yet are interesting, flexible projects where someone with a lot of creativity and talent could have a huge, highly visible (and valuable) impact on the entire Drupal community.

Read more
jpetso's picture

SoC 2007 application: RCS abstraction for the Project module

For this Summer of Code, I'll apply for reworking the Project module to free it of CVS specifics. The greater plan is, of course, to get SVN support into project.module (and pave the way for other RCS backends), but if I am to believe knowledgable developers like dww and chx, getting the revision control functionality abstracted out into an RCS API module is already a lot of work. In case it should work out faster than expected ("unlikely" :D ) I figure I can still do the SVN specific bits in the time that remains.

You can find my application here. It's essentially complete, but before submitting it to Google I'm still waiting for feedback from dww, and yours can be helpful as well! As a short teaser, here's the introductory part of my application as copied from my website:

Read more
schnizZzla's picture

Community HelpDesk, the need for another Ticket System

Hello everybody,

I'm trying to setup a new project:

A HelpDesk is basically a way to communicate problems to the support team or webmaster. It can be a very powerful application that helps organizing user support workflows. Users are capable of tracking their own tickets and moderators and administrators can see the tickets in a organised fashion. They can react to these tickets trough the module and ideally there could come more functionality for different user support work flows as assigning certain issue categories to a moderator of that category.

Read more
greggles's picture

Dojo Lesson #5 -- Get your CVS on

Start: 
2007-01-29 03:00 - 04:30 Etc/GMT-8

Here's an event to track the class about CVS and the Project module on Drupal.org. If you've always wondered what everyone is talking about when they say "dww is the coolest for the new project release system" then this is for you: dww will be joining the call. If you have a module or theme that you would like to release on Drupal.org then you will learn how to add it, branch it, tag it, and create a project node.

Take a look at the class agenda to see the topics that will be covered.

Read more
Paul Natsuo Kishimoto's picture

x.y.z is no longer an issue target in Drupal 5.0

This message is cross-posted to the "issue tracking and software releases" group because of the 5.0 functionality that prompted me to write it,, but is primarily intended for the Issue Triage group. Perhaps I'm only groping for a larger audience -)

Now that Drupal.org is running 5.0 RC2 / HEAD, project.module has seen some great changes - among them is that "x.y.z" is no longer accepted as a version for issues.

Read more
dww's picture

Help test 5.x core (and project*) on scratch.drupal.org -- become a project ninja!

the Drupal Dojo sounds great, and i'm happy to join the efforts (as both student and teacher, it's a whole spectrum, not a bit). anyone who wants to dive into Drupal development right now can help by mercilessly beating on http://scratch.drupal.org to test out the latest 5.x release candidate code, and submitting issues (with patches, if possible!) about any problems you find.

Read more
dww's picture

Additional resources about the release system

I've noticed a couple of other helpful resources on there in The Wild(tm) relating to my efforts on the new release system. I figured it'd be nice to list them all here, so other folks can a) benefit from easy access to the additional info and b) add to the list as they see fit. Perhaps some of this can/should be linked to from the CVS handbook pages about the release system on d.o? Anyway, here's the list...

Read more
Subscribe with RSS Syndicate content

Issue tracking and software releases

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week