Re: Why we need a new release

Am Donnerstag, 18. Mai 2006 09:20 schrieb Benjamin Schieder:
> Hi list.
>
> We need a new release, and we need it soon. Why? Here's a few reasons:

Hi all,

first of all thanks to blindcoder for bringing this topic to the mailing list. 
I think we all agree that a new ROCK release is long overdue. So this 
discussion basically revolves around how to do it (right).

In fact we (the ROCK developers) have already been working on stabilizing 
trunk for an official release since CLT 2006. This process is almost done and 
trunk could be made into an official release within a few days.

So let's focus on some specifc points of "How to Release":

1) Versioning: seems to be an ever-lasting source of discussion :)
My approach is to start with a simple versioning scheme and improve it as 
necessary (and possible, e.g. wrt. to manpower): the next release would be 
labelled 2.5.0 (others may suggest 3.0.0, or something in between); further 
releases with minor changes would increase the last part (tiny version), 
those with major changes would increase the minor version. Real big changes 
like incompatible changes to the package description format, or script 
calling conventions would justify a major version increase.

Note that with these scheme does not know stable vs. unstable releases (like 
e.g. linux 2.6 vs linux 2.5) - all releases are stable -, nor does it imply 
strict API compatibility between minor versions (because of lacking manpower, 
basically). The vague notion of major vs. minor changes, however, may be 
developed over time to reflect strict API compatibility checking.

2) Revision control:
Of course, if we do an official release of trunk, we want to somehow mark this 
revision of the svn repository as an official version. As with svn, we can 
either use tagging or branching. If I got the difference between the two 
right, I suggest to use tagging for at least the _next_ release, because I 
think we won't have the manpower to maintain two or more branches in the near 
future.

3) Official binaries (the Download section):
Several binaries should accompany each official release:
a) a compressed (tar.bz2) archive of the ROCK sources (since we shouldn't 
assume ROCK users have svn installed, or know how to use it)
b) ISO images for Crystal (our 'show-case' distribution) and bootdisk targets 
(at least for x86) built with this release
c) the .gem and .tar.bz2 binary packages from the ISOs above, available as 
separate downloads

4) Release day (aka. ETA - 0):
before making an official announcement of a new ROCK release, we'd ideally 
have the respective repository revision tagged appropriately, and have the 
binaries as described above available for download.

Finally, regarding the points I think which are not directly related to 
releases:

>
> 1. Just look at www.rocklinux.net, section "ROCK Linux News". Recognize
>    anything? This "News" entry is 18 months OLD! Not to mention that the
> link is dead. The "Update" box... ehm... does it show anything else besides
> Dilbert and Userfriendly comic announcements?
>    The "Security" box has at least 4 dead links.

Maybe add svn commits to the "Update" box, package updates as observed by 
Check-Version to "News"? There's certainly room for improvements. Maybe give 
admin privileges for rocklinux.net to more developers?

>
> 2. The Bug Tracking System is a joke. Noone is really using it. It contains
> bugs that are now 2.5 YEARS old. Obviously, nobody cares about them.
>

I have to disagree here. AFAICS the bug tracking system (flyspray in our case) 
is used where it seems practicable. There's no gain in sending a bug report 
to flyspray when someone is already working on a fix, which is the case for 
most bugs in ROCK afaik. 

As for the 2.5 years old bugs, I do agree that obviously no developer cares 
about them ;) However flyspray _has_ helped to keep track of bugs and fix 
some of them, with minimal overhead. 

It is interesting in this context to think of an article I've recently read 
about the ever-growing number of bug reports in Redhat's kernel bugzilla 
(currently in the hundreds). Looks like we're not the only ones having 
problems with bug tracking.

> This leads to 3. Everybody thinks ROCK Linux is DEAD. Let me spell it:
>
> 			  D        E        A        D
>
>    Dead. Unmaintained. Stopped working on it. In the last few days since I
>    released LVP, the overwhelming majority of feedback was: ROCK Linux? Is
>    that even still maintained? I though everybody stopped working on it.
>
>    Don't believe me? Just look at the Pro Linux announcements comments:
>    http://www.pro-linux.de/cgi-bin/NB2/nb2.cgi?show.9709.3010.
>

Maybe this little euphemism helps: ROCK == 0xDEAD == 57005 :)

Seriously, I ascribe this common misconception to a serious lack of PR 
regarding ROCK. Releases on a regular basis would certainly help to gain 
attention. 

We should also consider making day-to-day changes to trunk more visible to the 
public, see e.g. my comments on the "Update" box above. We could also send an 
automated newsletter to rock-user, summarizing recent changes to trunk.

>
> So, I ask the Triumvirate of patch appliers: Tobias, Thomas, Clifford:
> We need a _serious_ Roadmap to the next release. A "when we have a nice
> iso" just doesn't cut it.
>
> If we don't do a release soon, we might as well make the public view on
> ROCK a reality.

I wholeheartedly agree. As written above, I think trunk is almost ready for a 
new release. So let's do it :)

With best regards,
	Stefan Fiedler

>
>
>
> 	Benjamin
>
> --
> Benjamin 'blindCoder' Schieder
> Registered Linux User #289529: http://counter.li.org
> finger blindcoder-1k+CIuW/[email protected] | gpg --import