Offering to maintain Feature Server (fserver)

we had a D7 branch with a similar need, but it was again only a short-interest. So that branch was removed. I will not add a D7 branch until several people commit maintaining it. Fserver does not need, by any means, to be D7 for functionality. That is a deployment tool, and it can be D6 and still provide D5-D8 modules by any means. It is in nearly all cases not a part of a normal drupal site, so it does not need to be D7 for this reasons either. It will mainly be a stand-alone installation.

well the point is, it does not make reopening a second branch, if the community struggles maintaing even one. So rather stick heads together for one branch. Iam not goint to really stop a D7 branch, but at least it must be some serious maintainership, not jsut some checkins.

Check the D7 branch here, its a good port already

Maybe we get a compromize, zou incorporate all the patches missing in the D7 branch ( look at the issue queue ) and stabalize it. if that works out, iam willing to add a D7 release, otherwise we just push it into the D7 branch without making a release, for maybe someone else to continue. What do you tihnk?

@btopro - Any update on your progress with the D7 branch?

I know the merits of keeping this as a D6 project only, but we still have a need to try to get our Features Server working in a D7 environment. I am using the D7 branch - and see much progress has been made.

What are the major blockers to seeing D7 branch continue?

We've been working on a port of Feature Server to D7 for some time.

It's getting very close to feature completion. Most of the work left is with the actual UI for creating projects and releases. The API and entities required are pretty well defined.

If you'd like to look and provide feedback that would be great: https://github.com/coldfrontlabs/fserver

We're hoping this can be merged into the d.o project as the official D7 version which we would maintain.

You can find information about the architecture here: https://github.com/coldfrontlabs/fserver/blob/7.x-1.x/README.md

Hello, thanks for all your work!

Its looking like its a rewrite which is, looking at the age of fserver, something which can make sense for D7. Did you test any migrations or would that be not possible - in addition, comparing the code sharing, it looks like the d7 branch does not share to much code with the d6 branch, right?

How long would be you commitment to maintain the d7 branch?

We use it everyday for deploying code to clients. Though we use more of the API functionality than the UI so that's why it has taken this long to get what I would consider a "publicly usable" version. We have a vested interest in fserver continuing on as a maintained module. We actually have a dedicated staff member to maintain our release tools which includes fserver.

The code base is for all intents and purposes completely different. We started from the beginning on everything. It is not a direct port by any means.

Right now there is no upgrade path, but there could be. The projects and releases are their own entities so migrating some of the data from the nodes in D6 to them shouldn't be a problem. Other data (i.e. taxonomies, stats, etc...) are part of the "Project page" and "Release page" nodes. They store superfluous information which is only necessary if you want to run your own mini Drupal.org. So we should have a home for that data too.

The only major caveat is that the URL path to the fserver release XML feed are different than in D6 (due to the way Services builds URLs). Meaning that the project info statements in the .info files for those migrated projects would need to be updated. Meaning extracting, updating and repackaging releases. Not an ideal situation.

There are still several of features found in D6 which aren't in the D7 one. Mostly some views showing most recent releases, most recent projects, as well as a service call to get the list of all projects/releases on the site (as you do on d.o at http://updates.drupal.org/release-history/project-list/all). But those can conceivably be submitted as patches or just let folks create their own.

I know some may disagree with how the UI portion of the module is built. In fact I'd like to split the project page and release page nodes from that module and into the a submodule called fserver_pages or something like that. That way all data containers could be enabled as needed and anyone wanting a different UI for fserver can just disable the stock one and build their own module. That way we can avoid issues with people disagreeing with the use of Panels in favour of DS or Context with blocks for the project page layouts (or at least minimize such discussions).

The only other question I have is regarding the version numbering. If you agree to merge the repositories and let us maint the 7.x version, could we use 7.x-2.x since you've already had a previous 7.x-1.x branch? That way we don't have to support any or installations of the 7.x module or offer upgrade paths.

Thanks.

Well, due to not only the complete rewrite but rather a change of the architecture and missing some of the most important features ( projects feeds ) are for now blockes.

I def. need more people with fserver running looking at this and having a different angle on the project. We need, if offering a D7 port, continue what has been done or cut of the migration path ( for me, thats ok - all people wanting to stay on the old ways can stick with D6).

But things like project feeds, fserver-package and all this kind of things ( drush tools ) have to be part of D7 before we put this as the legit "next version".

I hope you dont get me wrong, iam very positive about this new version - but still, we have to get it from "you did what you need most" (and thats 100% legit) to "possible to do, what people do with it". Since fserver is rather a backend / deployment tool, UI / Theme questions should not really be a big part of the discussion for most. If people need sexy UI on top of fserver for parts of access to the customer - i suggest building a second platform, fetching data using RESt.

Just to be clear, the individual project feeds work and are fully implemented (i.e. those required to download/update modules). It's only the feed which gives the entire list of all projects (which isn't used in Drupal as far as I can tell...). It's a potentially large file so generating it is expensive computationally. But I can add that as the index method or an action in Services. Just have to find a nice way of generating it and caching it so the site doesn't explode if there are many thousands of entries.

The module is very much an API so adding the other features shouldn't be a problem. Though I'm not 100% on which drush commands were available in the D6 version (i'll look at what was them and mark them for porting). The rest of the issues are just Views on data which need to be created.

I'll post back once I have those three things implemented.

Thanks for all the informations.

To the all projects feed, it is used by some module and is pretty usefull. E.g. https://github.com/EugenMayer/update_feed_api wiht update_feed_cck and drush_make_ui .. we use this in combination with the feature server to maintain make files. Since you need to know what modules a server offers, you need the all_feed https://github.com/EugenMayer/fserver_bonus

But actually, of course its not depended on what i use in general or what i like, i would rather stick to be "anything that has been there and is not clearly legacy / bugged / useless" should be in the 7 release, so people can just port manually. That means, i dont see you in charge to provide a migration - that can be a community engagement. If someone wants to have a port /migration, let those do the contribution.

It would be great to have an update on the important drush commands like fserver-package and the others and then, we need some docs ( barebones ) for the new D7 version:
- installation
- basic terms ( ECK.. )
- Known Issues
- Important changes compared to D6

With those in place, we can start moving the project into the official repo.

i hope you are fine with that kind of approach and once again, thank you for the contribution!

We'll implement the all project feed. As mentioned, just have to find a way without making the site explode.

The relevant drush commands will be upgraded as well.

Yeah, that's the main reason to get it on d.o is so other contributors can start writing code.

As for docs, we have some stuff started using http://beautifuldocs.com/ so it'll be committed with the project and kept up to date that way. Having some d.o pages is probably a good idea too.

Hi!

Just wondering if there has been any action on releasing a D7 version of fserver now that Drupal 8 is out and Drupal 6 will not receive security updates after February 2106.

The other question should the title of this issue be changed? The majority of the comments are related to a Drupal 7 version and not to the original maintainership request. Otherwise maybe a new issue should be started with this issue marked as a related issue.

It has been 3 years since this issue was touched. I am just trying to see if we can somehow breath some D7 life into this project.

God Bless!

Frederick

Actually, I think it would make little sense to work on the 7.x version now unless it's almost ready to be released : a D8 version would have to be quite different, so any work should rather go there.

Actually, fgm, I think that a D8 version makes little sense. With configuration management in Drupal 8, features and the feature server will most likely go the way of the dinosaurs. But maybe I am wrong, however I thought that with CMI storing configuration in files instead of in the database there would be no or little need for features. Someone else can maybe explain this situation better than I can.

The fact is Drupal 6 will soon be unsupported. The feature server has a Drupal 6 version that works.

It also has 2 maybe 3 Drupal 7 versions but because of lack of "something" the different groups did not work together to get a Drupal 7 release out the door. I think 2 groups combine their efforts to make the Drupal 7 Dev version that is not ready to be use and the effort died there. Coldfront Labs Inc. has developed their own D7 version of the feature server which does not have a UI. They have this on github and in a blog post said they were trying to get the fserver maintainer to take their version as the D7 version but it seems this has not happened. They also state that they are using this in their company on a daily basis. I will most likely test their version out and see if it works for me. Since I am basically starting fresh I do not need to worry about an upgrade path like some others will.

My post here was in hopes that maybe some of the developers would think it was time to work on the D7 code that already exists and get it ready for production.

God Bless!

Frederick

Fredecickjh, you are obviously right in that a D7 version ought to have been created instead of multiple partial incompatible works. But of course, this is not how things turned out, and D7 is behind us now.

I have to dissent on the other point in your post, though : Features Server is basically not about CMI/Features, but - at last for us - an alternative to the d.o. backend for update.module, still with us for the D8 lifecycle, to support update module for any package not hosted on d.o., which always exist on real sites, and could easily be more numerous on D8 sites with the expected reduced number of small-features contrib modules used and a matching increase in custom code, meaning the need becomes ever higher.

This is why I'm still running a PF6 fserver, and since I've mostly done D8 work for the best part of the last three years instead of D7, would rather expect to see any unitary (as opposed to fragmented as happened on D7) work be done for the current version of Drupal, not the obsolete one.

But of course, it would still be better to have a D7 version than only D6. My point is only about something starting (again) from scratch.

I am closing this issue, since there haven't been follow-up actions as described in Taking over unsupported (abandoned) projects.