Do we need an Elive 3.7 Alpha Category section

  • 1-Create a Category(section) Elive 3.7 Alpha so each ELive 3.7 discussions about different topics will be in their "own tread"
  • 2- continue like this

0 voters

My point is that instead of talking about Bios, dropbox, screen config in the same thread, if we create a category (section) for 3.7, each " SUBJECT / TOPIC" will be cristal clear.

We'll have separate discussions, one thread/topic per subject.

Yoda
.

ARandR one topic

GRUB

FileSystem question / potential bug

and so on...

We have "betatests" section (#get-involved:betatest) that we can use for our test / results / feedbacks (this is its purpose in fact), where the actual 3.7.0 thread is flying like a chat, referencing things about that (specifically) version

The point is that development happens fast, we want a handy way to: report -> fix, report -> fix, report -> fix (that's my biggest interest, handy and fast tools, for all). Actually we are doing this in a not-bad way (and being updated of every issues talked by others in the same thread)

My suggestion is that using the actual approach, it allows to "park" (forget) the actual issues in the 3.7.0 version when 3.7.1 will be ready (with all of them fixed, or most of them at least), where we can start a new discussion / betatesting opinions about what the new version requires / has etc

We could eventually even delete these threads after they are done, but i dont found it very necessarily and also provides a "focused" source of information of issues found on every version (let's say, user downloads 3.0.6 and has an issue, there's a talk specifically for this version)

In other words, we don't want (any) issues in every next version built :slight_smile:

1 Like

You have a point, users may want to search for a specific issue that they may have (in a stable version for example), and its better to found if they are separated in different sections

by other side, we are testing an alpha with lots of changes, and there's a lot of reports lol (and entire different desktops), I would say "we should not care much about having tons of threads for a not-yet-ready version, better to do that for more public / ready versions"

all my 3.7 questions or comments or feedback will be in
https://forum.elivelinux.org/c/get-involved/betatest

with a clear subject name.

One subject/topic per thread...

Yoda

I should not do that yet for early alpha's, they are not even public :thinking:, too many threads and it could confuse users too

Also should be included the full version, with the 0: (3.7.0)

@triantares ?

but also, we should not open duplicated things (things already reported in trello for example) or :exploding_head:

1 Like

Maybe an idea to do the numbering like the Kernel? Even last numbers stable and uneven testing (beta)?
Or are you intending to number the stable 3.8?

Getting alpha's out to the general public is just asking for mayhem. Considering all I'd go for publicizing the beta versions for discussion. Apha is just too breakable and too open to divergence.

1 Like

I tried that but is not possible to follow :slight_smile: , when you upload an "even" and then you found something fast to fix it becomes uneven lol, or another solution is to just jump over the numbers (always release as even), in other words: ignoring entirely uneven numbers :thinking:

described here Elive versioning numbers assigned to releases

Yeah, agree with that, i would put everything on single threads for the alphas because of that, but also because is faster for us (all) to talk like a chat, in a fast way discuss + fix, discuss + fix (searching for threads and switching the web page everytime is slower, less efficient imho), its better to have that "good structure" (which i agree with) for a more ready versions (beta)

As the link previously show, there should be: alpha, beta, release-candidate, stable (with their numbers)

2 Likes

Related: I just added this small howto, feel free to improve it :slight_smile: Forum guidelines and how to write your posts

mentions: @stoppy98, @Rebel450, @Franc, @Terry_Rosinski

2 Likes

improved doc with specific examples

1 Like