OpenWrt Forum Archive

Topic: Backfire 10.03.1-rc4

The content of this topic has been archived between 1 Jul 2017 and 1 Jul 2017. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

They are configured differently. If you look at Oreon for example, snapshots are much smaller in size than release builds, meaning that many packages are omitted in snapshots. Last time I tried a snapshot build, I bricked my router. Ethernet ports were not working and I could not connect to wireless as well.

Yeah, but if you build your own image you can choose which packages to add.  Have you read this?  It's pretty easy to follow:

http://wiki.openwrt.org/doc/howto/build

What you actually should read is    http://wiki.openwrt.org/doc/howto/obtain.firmware

Both branches offer all 4 possibilities. stable is stable and trunk is bleeding edge.

How serious bugs you WILL encounter when employing bleeding edge, depends on support status (rocky drivers... which are reverse engineered) and maybe also on developer:

When developers drink and code more mistakes happen. And obviously, OpenWrt developers like booze. Some seem to be real booze-gourmets.

Well, it looks like the rc5 might be finally made in the near future, as the Backfire branch has already been branded as rc5:
https://dev.openwrt.org/changeset/26767

Oh good, just another 6 months to go then.

Sorry, couldn't resist :-P

So there isn't enough manpower to sustain updating trunk and at the same time grooming the stable branch. Big deal.

Did I already mention, I am very happy with trunk? It works and works and works...

I could imagine, it is more important to put some efforts into the development of wireless drivers, porting to new kernels (as 2.6.32 is last LTS kernel anyway), new tools, etc.

But then again, I also use Arch Linux. If ye debian types insist of buying old hardware with solid driver support in old kernels ... bah.

Orca wrote:

So there isn't enough manpower to sustain updating trunk and at the same time grooming the stable branch. Big deal.

Why to try to maintain a stable branch at all, if that is the case? The first rc1 for "maintenance release" 10.03.1 was released almost 1 year ago, and it has been 6 months since rc4. Talking about an rc version for that period is funny. The current Backfire rc5 code is already quite different than rc1.

Like I said in this thread in March: even Mozilla/Firefox is now moving to a 3-month release cycle, where they released Firefox 4 in Q1, then FF5 will come in Q2 and FF6 in Q3 etc. They have scrapped the plan-two-years-ahead-for-a-major-release development style and have moved towards Google-style rapid releases with follow-up critical bugfixes, if necessary.

We have now been in the rc-phase of 10.03.1 for 8 months, and it is over 5 months since the last rc version, rc4 in November 2010. Trunk is so far ahead of Backfire, that releasing 10.03.1 will be rather pointless.

From average newcomer's perspective, it is helpful to have "releases" every now and then, as the daily trunk snapshots can be problematic and unstable.

Maybe OpenWrt developers could re-think the release strategy and release 10.03.1 as it is now in the Backfire branch, and then move on to stabilize the next release of from the current trunk, this year hopefully...

One option might be to produce stabilized snapshots every 4 months: allowing 3 months for new features and actual development, then stabilizing the trunk during the final month without other than bug-fix changes (to prevent introducing new bugs), and then just releasing the trunk snapshot at that point as the new release.

hnyman wrote:
Orca wrote:

So there isn't enough manpower to sustain updating trunk and at the same time grooming the stable branch. Big deal.

Why to try to maintain a stable branch at all, if that is the case? The first rc1 for "maintenance release" 10.03.1 was released almost 1 year ago, and it has been 6 months since rc4. Talking about an rc version for that period is funny. The current Backfire rc5 code is already quite different than rc1.

Ambition? I don't know. However, I am sure, the delay is caused due to lack of manpower. ;-)

hnyman wrote:

Like I said in this thread in March: even Mozilla/Firefox is now moving to a 3-month release cycle, where they released Firefox 4 in Q1, then FF5 will come in Q2 and FF6 in Q3 etc. They have scrapped the plan-two-years-ahead-for-a-major-release development style and have moved towards Google-style rapid releases with follow-up critical bugfixes, if necessary.

Ah, this is just marketing hype! They want to bump the main number up to 9 or 10 or 11 (Opera is 11), I bet once this is reached, they again will change this. Who, besides brainless people care about the damn number? And google-style releases? Uh, then rather give me Debian! Many people at google want to change the world, but they lack manpower. The VP8-CODEC needs a LOT of work. I am thankful that we have it under the correct license, but it needs a lot of work...! And as for the Apple contribution to WebKit, they started to play around with the software-parts, that they released under the BSD-license. But that's off-topic.

hnyman wrote:

We have now been in the rc-phase of 10.03.1 for 8 months, and it is over 5 months since the last rc version, rc4 in November 2010. Trunk is so far ahead of Backfire, that releasing 10.03.1 will be rather pointless.

From average newcomer's perspective, it is helpful to have "releases" every now and then, as the daily trunk snapshots can be problematic and unstable.

Honestly, I don't care. I am happy the code base moves on with new kernels, the drivers get better and better and new stuff get integrated! And the trunk-releases for download, are actually quite solid. I use them all the time (I update once a month) and it's good in my experience.

hnyman wrote:

Maybe OpenWrt developers could re-think the release strategy and release 10.03.1 as it is now in the Backfire branch, and then move on to stabilize the next release of from the current trunk, this year hopefully...

One option might be to produce stabilized snapshots every 4 months: allowing 3 months for new features and actual development, then stabilizing the trunk during the final month without other than bug-fix changes (to prevent introducing new bugs), and then just releasing the trunk snapshot at that point as the new release.

Sorry, I don't care. I am content with the hardware I bought (WR1043ND) and the price I payed for it 47Euros and I am very pleased with the stuff I can do with it. With trunk!

As for more computing power and more memory, I have a Seagate dockstar with the u-boot from jeff doozan and debian. I still don't know, how to conveniently install OpenWrt on the harddisc. There is documentation for debian, none for Openwrt. If I wanted more power and more RAM, I would go x86 with Atom or Bobcat and of course I would go with Debian!

If I was be bored, I would start advertising http://en.wikipedia.org/wiki/Freifunk in my neighborhood, for this you need cheap devices (definitely less then 50€) and solid wireless drivers. That is the niche for OpenWrt, and it fills it wonderfully. To remain good, we need better and better wireless drivers and for this I think regular kernel updates. This is where the sparse manpower should go and this is where is does seem to go. Besides lack of manpower, I don't see a problem.

Is freifunk-firmware really based on white-russian? [irony]Well, then we should stop the development and go for "something stable" if the people are not interested in using newest drivers anyway...[/irony]

To put it simply: with lack of manpower I would rather go for development then for stability.

I sure hope that this, and the above comments for that matter, don't come off as a complaint about the slow release of Backfire or anything like that. We should all remember the fruits we enjoy from the important work the devs do on their spare time -- demanding releases and ridiculing the long RC cycle can quickly sap the joy and motivation that drives them to do what they do!

That being said, perhaps a lot of the complaints could be allayed by providing more info on the status of things on the front page and the wiki? Perhaps users would be more positive if they were told that Backfire releases are far between, and that for such and such wellknown hardware one should consider trunk? Maybe some info now and then about major things going on in trunk, future directions, etc?

Rockbox releases a snapshot every few months.  They do test each release a bit before release. It would be great if openwrt would release a version every 3 months, it would really help increase the adoption rate of this great software.

You guys can *plan* the release cycle however you want. You could *propose* this or that information about the status be relayed to users. In the end, you are at the mercy of the creative drive of the developers. If you want things done sooner, do it yourself wink. Otherwise, take what is there now and use it. Myself, I always was a bit frustrated by the perfectionism in this and other F/OSS projects, as I am more inclined to get a workable piece of code, then move forward (as opposed to continually reworking that code). However, each method has its advantages and disadvantages, and *again* you are bound to the particular ideology of the developers. Being open source, YOU have the liberty to do whatever you want though, so there should be NO calls for doing things faster --

"Do something! Do something! No - YOU do something ;p"

(Last edited by db90h on 15 May 2011, 05:03)

I'm not advocating "faster" development. I'm just requesting a snapshot and builds of the tree every few months (every 3 months would be ideal). Ideally, the code could be frozen to new features a week or two before the release (mainly to prevent large scale changes just before a release).

IMO, this would really help increase the adoption rate of this great software.

saidiadude wrote:

I'm not advocating "faster" development. I'm just requesting a snapshot and builds of the tree every few months (every 3 months would be ideal). Ideally, the code could be frozen to new features a week or two before the release (mainly to prevent large scale changes just before a release).

IMO, this would really help increase the adoption rate of this great software.

Agreed. It's all just "marketing," really - what does "rc" (Release Candidate) mean? Or, more to the point, why are there four or five or more of them? In my view, you put out a single Release Candidate, people identify bugs in it, you fix those bugs, and call it a Release. After all, we're still down at the double-dot level, right? 10.03.1 will be the eventual number? Fine - take whatever you have now, call it 10.03.1, and start over with 10.03.2-rc or something.

For my own selfish needs, I'm just looking for up-to-date files on downloads.openwrt.org - I'll bet that there have been many bugs fixed since Nov 2010, but they're sitting around waiting for rc5 to be marked as ready, so we wait and wait...

In the end you can advocate or demand anything you want which does not change the fact that releases are slow and testing periods long. When there are >20 platforms to support you can't just take stuff and declare it stable. If you need something from trunk now then build it yourself and support it for your users.

jow wrote:

In the end you can advocate or demand anything you want which does not change the fact that

Yeah, that much is obvious.


jow wrote:

releases are slow and testing periods long. When there are >20 platforms to support you can't just take stuff and declare it stable. If you need something from trunk now then build it yourself and support it for your users.

If there is interest on the developer side to get support from the less technical adept users as well, one could offer some howto for extended testing.

Some procedures, or a real testing parcours to do after installation of a fresh build to find and exclude certain bugs. Generic or hardware-specific.

http://wiki.openwrt.org/doc/howto/user.advanced#testing

If testing is such an issue, it should be addressed.

While I am NOT an OpenWRT developer, let me defend them again by saying the only thing more frustrating to a developer than slow progress (yes, it is frustrating to them too), is users starting to tell the developers how to do their 'jobs' ;p. I guess that is frustrating for all professions, but it drives me crazy.

Like I said, since it is open source, you ALWAYS have the option of creating your own stable builds.

We're not telling developers how to do their job. We're just requesting a more reasonable release schedule. 10.03.1 has been an RC for a year? Some of us that are not developers cannot build our own without hours/days of frustration, but we would love to use the software and provide feedback. BTW, none of the posts above implied that we are not appreciative of the wonderful work that the developers have done. On the contrary, almost every post conveys gratitude for the effort put into the project. This is definitely not a case of US vs THEM, and I certainly hope that the developers dont feel that way. We're all on the same team here but some of us have been waiting for quite a while for a non RC release. Please don't answer "build your own" as for many of us this is not a viable option.

Btw, I had been running RC4 since November and decided to give trunk a go today. I had experienced a bunch of problems running RC4 on my wzr-hp-g300nh in client mode, and actually reverted back to using my trusty old wrt54g a few months back, but after upgrading to trunk today I can only say wow: Ultra stable, high speed and even an awesome new web UI to go with it! So to anyone using a wzr-hp-g300nh I highly recommend trying out trunk.

va1210 wrote:

Btw, I had been running RC4 since November and decided to give trunk a go today. I had experienced a bunch of problems running RC4 on my wzr-hp-g300nh in client mode, and actually reverted back to using my trusty old wrt54g a few months back, but after upgrading to trunk today I can only say wow: Ultra stable, high speed and even an awesome new web UI to go with it! So to anyone using a wzr-hp-g300nh I highly recommend trying out trunk.

I'll second that!!!!

First off, I love this project and I'm really impressed with what the developers have done, for free no less. No complaints here.

Second, I do know how to make my own builds, and have done that on occasion.

That said, for "production" use, it really is nice to have a stable release (stable meaning not only no crashes, but also that it's not a moving target) -- like your official releases. It's nice when the package repository is still there a few months later when I realize I need to install a new package. Stop me if I'm wrong, but I don't know how to keep the package repository working for any length of time when running trunk builds.

Not having installed OpenWRT yet, I'd also prefer some kind of "release". Not that it has to be marked "stable" or "beta" or something, but an SVN tag would suffice. So that people could run e.g. backfire_11.03 and when issues arise, everybody knows which release you're running. Otherwise it'd be "oh, you're running the version from last Monday, try the Tuesday version, but after 12 EST". Maybe that's not the case though and issue tracking around here isn't like that, I wouldn't know, as I'm new to OpenWRT. But an SVN tag would be nice, IMHO.

Thanks!

Seems like the manpower issue is the sort of thing automated testing is designed to address. Finding people with the right resources and skillset might be a challenge, though...I see there's been some discussion about this on the openwrt-devel mailing list (https://lists.openwrt.org/pipermail/ope … 09067.html), but it doesn't seem like anything has caught on yet.

Probably more importantly, I'm unable to locate a clear definition of what a stable OpenWRT release is. Doesn't seem to mean every known bug has been addressed, and I imagine there's more to it than simply making sure that images for various platforms build without errors. Who decides when a release is stable, and what criteria do they apply?

Orca wrote:
hnyman wrote:

Like I said in this thread in March: even Mozilla/Firefox is now moving to a 3-month release cycle, where they released Firefox 4 in Q1, then FF5 will come in Q2 and FF6 in Q3 etc. They have scrapped the plan-two-years-ahead-for-a-major-release development style and have moved towards Google-style rapid releases with follow-up critical bugfixes, if necessary.

Ah, this is just marketing hype! They want to bump the main number up to 9 or 10 or 11 (Opera is 11), I bet once this is reached, they again will change this. Who, besides brainless people care about the damn number? And google-style releases? Uh, then rather give me Debian! Many people at google want to change the world, but they lack manpower. The VP8-CODEC needs a LOT of work. I am thankful that we have it under the correct license, but it needs a lot of work...! And as for the Apple contribution to WebKit, they started to play around with the software-parts, that they released under the BSD-license. But that's off-topic.

Perhaps the FF number release number is marketing,

But they have actually changed their development practice, and I think it shows (compare FF5 to FF4)

http://www.infoq.com/news/2011/03/Firefox-4

Their development change could be described as:
- schedule driven development vs feature driven development (you can't have both)
- iterative development (90's (or before) software engineering term, or general engineering term)
- agile/scrum development (to use current terminology)

These all describe the same basic thing.

Developing in small increments (with confined goals), with each increment resulting in a stable release/product that may be built on in the next iteration.

In a couple of my employers, I have seen big differences in software development when a switch occurs from a feature driven release (2-? years) to iterative development, and I hope to see a similar change occur in open source projects. (which is also why FF is interesting to mention)

openwrt is a good and important project, that all of us wish continued success, and the suggestion of a shorter release cycle comes from this wish.

On my DIR-825 I was running 10.03.1-rc4 and it after a week or so it would have routing issues between certian WLAN devices and any other devices.  I didn't troubleshoot too much, but going to 10.03 beta fixed it so far.

PS: I would be for a more up to date release schedule that's quarterly or twice a year.

(Last edited by gyrfalcon on 9 Jul 2011, 07:38)

The question is, why the OpenWrt devels decided to offer a stable release additionally, since trunk is already very stable, at least for me. I encountered minor bugs, which were closed very quickly, but no stability issues so far.

It's a pity that, 10.03.1 needs so long to finally get released, but it is more important that a steady development is going on in trunk.

I don't understand your problems. Please, go to Arch Linux Forum and propose a stable release: https://bbs.archlinux.org/ Or better yet, demand one.