Proposal: Ditch the ability to have release nodes pointing to HEAD/master

+1

Git has no real attachment to master, and people never understand the whole HEAD thing anyway. So let's do it.

Tagging as something to figure out this sprint. Assigning to myself for lack of a better assignee.

+1000 from me. I'm one of those people who checks projects out from CVS and up until I learned about drush dl --package-handler=cvs this was an incredibly annoying process of having to check the release node for the proper branch and then change my commands accordingly. And there is nothing more irritating than doing a routine cvs up and getting the next version's code. Ugh.

I also estimate that this is the 3rd or so most frequently asked support request on IRC regarding CVS. Barriers to contrbution--. It's also something that requires people with site maintainer privileges to deal with, when someone wants to change the release HEAD is pointing to, and that very tiny group of people has much bigger things they could ideally spend their time on.

So given that, I'd be quite interested to see if there was a possible way to write a migration path for this (even to throw out as a "git low hanging fruit" task for one of the volunteers to possibly take on). Maybe even something that might be doable as a Google Code-In task? Something like...

1. Loop through that list of projects.
2. Find the name of the release node.
3. Create an according branch in the Git repo.
4. Commit all the code there.
5. Repeat.

(Of course, if I am showing ignorance here and it's actually far more complex, let's throw the idea out the window. The important thing is that we can reduce the amount of crying during the VC Project work. :))

LOL. I see what I wrote at the end there was exactly what you wrote in #1. Duh.

Yeah, I suppose the fact that we might *lose* code is a potential deal-breaker here. OTOH, I imagine we'll keep the legacy CVS mirror up for at least a few months after the initial migration. Hmmm.

And the weirdest browser caching behaviour award goes to Firefox 4 beta!

Ok. Unless someone comes up with an argument against this by our Friday stand-up call at noon PST, we're going to call this decision made.

Ok, fine. :P

http://twitter.com/DrupalGitGremln/status/29010644332
http://lists.drupal.org/pipermail/development/2010-October/036536.html
Melissa's working on a post on g.d.o.
I don't have availability to make a big stink about it in IRC today, but hopefully that'll take care of itself.

Sounds fine to me.

The "Active development on HEAD" doesn't work anymore once you have active development for Drupal 6 and 7, for example and it gets really confusing which branch is now which version.

Also agreed on automatic renaming of master to version with all these weird version names out there... :)

simplicity++

Posted to g.d.o, too: http://groups.drupal.org/node/102789

I would even go so far at to say that release nodes should only ever pick up tags and never branches. But not really a point worth arguing over. The main issue is getting rid of the 'HEAD' concept and I'm all for that.

So for this, I could still have a 'development' release node pointing to whatever branch (ex: 6.x-2.x) which could and most likely will be a moving target, and then a point release will still be a tag (ex: 6.x-1.0), correct? If so, definitely +1.

Re-reading the title, we're saying that a release could not be pointed to 'master'. But in Git, 'master' is just another branch. So if we're allowing a release node to be pointed to any branch, then master will be included, no? Maybe I'm not quite understanding the difference between a 'development' release node and a release node?

I would think it would be much simpler to just have 'release' nodes and allow them to point to any branch or tag.

The proposal is to only allow release nodes to be pointed at branches that follow specific naming conventions:

e.g.:

-7.x-1.x
-7.x-1.0
-7.x-1.0-rc2

etc.

There would be no way to point a release node at the "master" branch. Developers could still develop against the "master" branch (and any other branch they like - "foo-new-features", etc.) but tarballs would not be generated for them.

See http://groups.drupal.org/node/85269 for more details on the branch/tag naming stuff.

Incidentally, the only project I can think of where this would legitimately screw people up is Drush, which intentionally points its main supported release node at HEAD. (soon to be master)

I think we need to have some kind of workaround for them, since this is truly version-agnostic code and committing each fix to 3+ branches is going to be incredibly annoying and error-prone. Hm.

Sounds like a good approach. Though it would be great to be able to say we have *NO* release nodes pointing at master and if left up to maintainers it might be a long time before that would happen.

Speaking as a module maintainer: A-frickin'-men! (+1!) HEAD development pisses me off, and I never use HEAD myself for exactly the reason you list.

Git branching makes all of the problems with HEAD go away. Let's use it. It makes life easier for the migration team, developers, and advanced users checking out from a repo directly (or even just trying to grab a copy to make patches).

There's enough time that we could probably advise maintainers to move their release nodes off of HEAD before the switch, too. Not everyone would listen, but it at least would probably get a few people to solve the issue themselves before it becomes a problem.

@webchick: Well, you wouldn't commit to 3 branches. You'd commit to one, and then do a fast-forward merge for the others so that they all point at the same place. Agreed, though, that Drush is probably a legitimate edge case.

Talked over The Drush Problem™ with Sam in #drupal-vcs and he pointed out that one way to solve this would be to create a separate class of project nodes (maybe "Scripts"?) for this kind of version-agnostic not-actually-a-module-but-called-a-module-anyway stuff like Drush (cvs-release-notes.php would also fall under this category, and would be actually findable were it a project).

dww, any sense to how much extra work that would be?

This sounds like a great idea. I would suggest emailing the maintainers of all projects with HEAD releases asking them to migrate their code over.

We might also want someone to go through and fix up all of the "Abandoned Projects" owned modules and clean them up as well. That way, they are following best practices if any new maintainers take them over.

I tried to issue this query on d.o, but it sat there an uncomfortably long period of time, I think due to lack of indexes, so I killed it: (sorry if I broke something :\)

select count(*) from project_release_nodes rn INNER JOIN project_usage_week_release pu where rn.tag = 'HEAD' and pu.count > 0;

But IMO whatever nids come up in that search, those are the only projects we actually have to worry about. From cursorily browsing project_release_nodes, the vast majority of these seem like exceptionally old projects that no one gives a crap about anymore. (The unfortunate fact that all -dev releases have a last updated date of July 11, 2010 makes it a little hard to ascertain exactly).

++++1

My only thought is whether there is really a need for the legacy support. While it doesn't seem to add a ton of additional work at some point, sooner or later, eventually, we'll want to have these go away totally. Given the suggested handling for non-core-version-specific projects (drush) is there really any reason we shouldn't just unpublish all these nodes and even notify maintainers in advance that they're about to go away?

Unpublishing a release node means a big red "OMG this module is unsupported, run in terror and hide your children!" message in the admin of any site running it. Depending on the module in question that could be, um, a lot of very angry site admins. :-) (Yes they're using dev releases, but many modules don't bother with real releases for various legitimate or moronic reasons.)

If we can coax module maintainers into fixing it themselves, though, that's the best option. Abandoned modules we can just try to script and if those break, oh well, they are abandoned.

As one of the few who actually listened to and understood the reasoning behind developing in HEAD, all of my projects have -dev releases pointing at HEAD. I'm one of the biggest advocates of this functionality in Project* when working with CVS.

But in Git, "master" branch has no special significance in Git; its just the default name of the default branch. So none of the Git mirrors of any of my projects have a master branch; they simply use branches named 7.x-1.x, etc., since well-named branches are more important that seemingly-magic ones. http://github.com/JohnAlbin

+1 to this proposal.

the aegir project will continue not being able to use drupal.org if this goes through.

we're in the drush hole.

I talked to dww about the different-branch/tag-validation-for-different-types-of-projects thing, but it's going to be a lot of work, and not something we can have in place without pushing launch off quite a bit. :\

So, question for Adrian: Since our branch naming conventions are now simply "N.x-N.x" could Drush, Aegir, etc. get by with "1.x-1.x", "2.x-1.x", and so on? You wouldn't come up in a filtered module search for "Drupal 7 modules", I suppose, but then again you're /not/ a Drupal 7 module.

So does this issue mean we're going to ditch the ability for a release node to follow *any* branch? Or just that it means we're going to lose the ability to follow the magic "master" branch?

Those are two very different things.

@adrian: If we retain the ability to follow a specified branch, will aegir be OK?

I think if we lose the ability to follow a specified branch (as we do now with dev) then I would retract my +1.

Hm? No, definitely not. Release nodes will still be able to point to branches. But the branches they're allowed to point to must follow a specific naming convention: "7.x-3.x", etc.

You can also create branches named "booger" or "bananapants" for experimental work or whatever you want, but can't point release nodes to them. We need this consistency for Update Status, testbot, and other things.

The proposal here is simply to remove "master" (analogous to HEAD in CVS) from the list of branches you can point release nodes to, in favour of consistency and lack of special case handling.

pish, pish, dont waste time and effort supporting too much -dev release nodes. Anyone who runs those can use a version control system anyways. So totally +100 to this.

So one answer to all this is:

1. We require the n.x-n.x branch naming.
2. We allow branch releases (release nodes that follow branches)
3. The first digit is only by *convention* (for modules and themes) the drupal release.

Using this, a project like aegir or drush, would use 1.x-1.x or something like that.

Doesn't this work?

Just had the same idea that rfay had, what about making a special case for projects that are version agnostic. Instead of 1.x-1.x, my suggestion would be "x.x-1.x" for the following reasons:

- There is no need to use two version numbers if the first one is *not* drupal core release IMHO
- You can only either use "x.x" or a valid core version (5.x, 6.x, 7.x, ...)

I'm in the simplicity++ camp.

I am in favor of dropping support for special HEAD/master releases as proposed.

For the 3388 outstanding such cases, I suggest a migration path (even if a manual, maintainer "do this, this and this" recipe), and spamming the maintainers of those modules as far in advance of the code change implementation as possible.

And of course, solving the Drush and Aegir situation cleanly -- although I have no good suggestions at this point on how best to do that.

In general, I'm in favor of:
1. less complex code
2. less complex repo management such that more people can better understand the best way to manage their modules, themes, etc.
3. less stress and work for Derek! :-)

#34 is interesting. Derek, is this possible?

Just to mention that #37 sounds reasonable, but IMHO it is more error-prone than #34(do it accidentally), unless we show a big red light on the form choosing, so the user can be enough warned about what he is doing.

Sounds reasonable to me. drush/aegir are extreme edge cases and we should only handle them if it is easy. Its not that terrible if drush/aegir move off of d.o. for VCS.

Not sure if "x.x-1.x-dev" or just "1.x-dev" is better, I guess the second one is easier to accidentally misuse?

I don't get #40, I think drush/aegir have the same problem for dev and point releases as they are both core version agnostic?

The main reason for not bothering with making a named branch and stick to HEAD is that you have to go round the houses with CVS and branch THEN re-check out all over again. With a git checkout you can branch and switch much more easily, so forcing people to make a branch is a very minor imposition.

+1 from me.

Sent an e-mail to Moshe and Adrian asking them to chime in with more details.

Like I said, go ahead. I don't object. adrian's comment has no substance and shouldn’t delay anything either IMO.

Moshe, the go-ahead signal from you is clear. Thank you for that!

I think the Git team also needs to understand your take on drush's specific requirements so they can make an informed decision about addressing those requirements (or not) rather than writing drush off as an edge case and not knowing where the proposal falls short.

I can substantiate some things here, but I feel I will be rehashing what was already said. Nevertheless, I can make a clear wrap up, after reading the whole issue.

1. Drush and Aegir (provision, to be more precise) are Drupal version agnostic. In order to function properly, Drush is currently forced to use 7.x as a supported version, but that's actually false: drush supports multiple drupal core version. Same for Provision.
2. Having an exception for scripts (#322626: META: Package and version non-modules for download) or just allow non-core branded branches (x.x-1.x or 1.x instead of the traditionnal 6.x-1.x) would solve the problem for both Aegir and Drush

Regarding (1), I feel the problem is that we are using the branch name to *also* mean "what drupal version is this compatible with". I understand it makes things very explicit for people, but maybe it's not necessary... I don't want to diverge massively towards a potential consensus here (x.x-1.x or scripts seem unchallenged so far) but I feel that maybe we need to rethink the whole thing here. I always had the feeling that embeding the drupal core version in the branch name was odd: I'm going to create a new branch for my D7 port anyways: there will therefore be no name clashes, so why bother?

In otherwords, let's say I'm running mymodule-1.x on D6, and I start porting work on D7. I will create a new branch, called mymodule-2.x and code there. I will port changes between branches and all. If I have major new features or architectural changes, I will just make mymodule-3.x, which I will *not* port to D6 (unless I am insane and masochist). (Replace "mymodule" with "views" here to see more clearly what we're talking about here.)

Would it make sense to drop the x.x prefix for *all projects*? (Not just scripts?)

Otherwise, if we allow projects to have branches that are not mapped to a drupal core release (either as separate project space or with an exception), I'm perfectly okay with this. In fact, I believe that if drush can manage to survive on CVS with that crappy naming convention right now, I don't see why we wouldn't be able to do the same thing on git...

We're really talking about a *new* feature here, that has nothing to do with ditching master, which is "allow releases not mapped to Drupal core releases".

Of course, if we're going to re-engineer the code, might as well try to get that into the design...

In short: no objection here.

Thanks for chiming in on behalf of the Aegir team, anarcat! :D

The "7.x" prefix isn't really there for convenience/protection of developers, but more to protect our end users. It makes it very explicit at a visual glance what code is for what version of Drupal in the 99% case where the project is a module or theme and Drupal version of course matters very much.

But it's also convenient for technical users who like to deploy modules/themes from Git directly, or even just work on patches from their local Git checkout. If I do git branch -r and get back mymodule-3.x, mymodule-2.x, etc. I need to git checkout to each one individually to know which one(s) apply to my version of Drupal, else I have to go back to the project page and click on each release node individually to figure this out. If I see 7.x-something and 6.x-something, it's extremely clear.

So given those things, and also given that the discussion at http://groups.drupal.org/node/50988 about branch/tag naming conventions reached pretty overwhelming consensus already and we've documented the existing naming conventions, I really don't think we need to re-open that discussion again, especially if what we've outlined here works.

So I'm going to go ahead and mark this back to RTBC, assuming that anarcat can speak on behalf of adrian on these matters, and that given his feelings, it sounds like Drush/Aegir can still exist on d.o as long as we have the ability to do "Drupal-branch-neutral" naming conventions in some form.

Sounds like we can safely move forward with dww's proposed changes, then, assuming that we allow those alternate branch constructions.

Reopen if it's a problem.