Re: Looking for xorg-x11-* package co-maintainers
Le 22/10/2014 11:25, Hans de Goede a écrit : > Hi All, > > As you probably know the graphics team always has more work to do > then we've manpower. > > As the person taking care of various old xor-x11 apps / utilities > and utility libraries I'm looking for co-maintainers to help with > maintaining these. > > You do not need to be a hardcore X hacker to help here. 2 things > with which I really could use help is keeping all the various bits > and pieces up2date with upstream releases, and taking care of > simple (packaging) bugs were possible. > > To give you an idea, currently I've this list of packages which > still need to be synced with upstream for rawhide and Fedora-21 : > > -xcb-proto 1.11 > -libxcb 1.11 > -xrandr 1.4.3 > -libXfont 1.5.0 > -twm-1.0.8 > -imake 1.0.7, gccmakedep 1.0.3 (imake) > -libICE 1.0.9 > -libXft 2.3.2 > -intel-gpu-tools 1.8 > -xkeyboard-config 2.13 > -xcb-util 0.4.0 > > Note these are the upstream package names, the Fedora package > names are not always the same. Also in some cases someone else > may have updated them since I noticed that they were out of date, > I've not rechecked the list recently. > > If you want to help out with maintaining these, please let me > know! Hi, I'm not a packager but I'm interesting in helping. I'm not fully aware of all "rules" but I'm ready to learn :) Don't hesitate to ping me on irc (I'm starmad). Regards, Matthieu. > > Regards, > > Hans > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New release cycle proposal (was Rolling release model philosophy (was ...))
Hello all,
I'm not a Fedora developer, nor package maintainer. I'm a French Fedora
Ambassador for a long time. (I should say "I was" cause I don't do to
many things last time, just wake up every 6 months for Fedora releases
and other events).
I'm also a developer but that's not about Fedora.
While reading this thread, an idea came to me about the Fedora release
cycle.
First, while discussing with fedora users, from events, friends, and
parents (real Adam's uncle Bob), the following points can be inferred:
- They like the blending edge part of Fedora.
- They want stable releases.
Not always in the same time, it's depending of user profile. It seems a
little antagonist, but that's what they want.
(By the way, they are mostly happy with Fedora)
What I propose is a new release cycle: One release every year and a
"preview" (not sure of the name) release between them.
- Small features can come in whatever release.
- Big features (libc, anaconda, systemd, gnome3, wayland...) can come in
preview release only.
- FedoraN releases have a lifetime of 2 years.
- FedoraNPreview releases have a lifetime of 6 months.
For example, if we start from Fedora20 at beginning of 2014:
- Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of
doing)
- Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol)
- Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way
of doing)
- Fedora22Preview(jul 2015)
- Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol)
- Fedora23Preview(jul 2016)
- Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol)
- ...
Preview version doesn't mean unstable. It means version as we have now,
but more tolerant to bug ("Here the new version of Fedora with latest
features. We make our best, but maybe not enough. You're aware of it.")
Stable version is mainly preview version stabilized plus other (small)
features.
For users:
- Users wanting stable (long time support) version can install it every
2 year.
- Users wanting new versions but stable can install it every year
- User wanting blending edge can install a version every 6 months
For devs:
Still a version every 6 months, new features can still be added. Just
one out of two versions has to be more stable (no big feature)
For QA:
Still a version every 6 months. More QA for stable versions
For Ambassadors/Marketing:
Still a version every 6 months. Nothing change.
For maintainers/packagers:
For now there are 4 versions at the same time: Fn-1, Fn to maintain and
Fn+1, Rawhide in dev
With my proposition:
- Between Fn and Fn+1prev: 2 versions (Fn-1, Fn) to maintain and 2
versions (Fn+1prev, rawhide) in dev
- Between Fnprev and Fn: 3 versions (Fn-2, Fn-1, Fnprev) to maintain and
1(2) version (Fn, rawhide) in dev
During 6 months, there is one version more to maintain, but changes
between Fnprev and Fn are not breaking stuff.
We could also create some king of "half end of life" : stable releases
get all updates for 1 year, and security updates only for the second
year. This could reduce maintainers' work.
This way we reach the two worlds:
- Users can chose the version they want (long time support, stable,
blending edge)
- Usual dev work for preview versions, but less QA (We have to admit it)
- Usual QA for stable version, but less dev
- Number of versions to maintain doesn't explode.
- We can have versions more rough, simplifying dev and still allowing
"real" user feedback.
- External editors could base their products on stable versions and skip
preview ones.
What do you think about this ?
Regards,
Matthieu Gautier.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New release cycle proposal (was Rolling release model philosophy (was ...))
Le 06/11/2012 19:48, Peter Lemenkov a écrit : > Hello All. > > 2012/11/6 Matthieu Gautier : >> For example, if we start from Fedora20 at beginning of 2014: >> - Fedora20(jan 2014) is a stable release. (Fedora18 eol, actual way of >> doing) >> - Fedora21Preview(jul 2014) is an "unstable" release. (Fedora 19 eol) >> - Fedora21(jan 2015) is a stable release. (Fedora21Preview eol, new way >> of doing) >> - Fedora22Preview(jul 2015) >> - Fedora22(jan 2016) (Fedora22Preview and Fedora20 eol) >> - Fedora23Preview(jul 2016) >> - Fedora23(jan 2017) (Fedora23Preview and Fedora21 eol) > So you not a maintainer but you still suggesting that we, maintainers, > should do 2 times more job by supporting several simultaneous Fedora > versions instead of 3 right now for more than two years. And that's > all just because you think it's a good idea to spend my personal time > on the rreleases I'm not using anymore. No, I never suggest that. Preview versions have a timelife of 6mo instead of 12. Stable version have a lifetime of 24mo (12mo for regular updates) instead of 12. Regards, Matthieu Gautier > > How about NO? > > https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mbfshfloal1rpdotto1_1280.jpg > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New release cycle proposal (was Rolling release model philosophy (was ...))
Le 06/11/2012 20:05, Peter Lemenkov a écrit : > 2012/11/6 Matthieu Gautier : >>> So you not a maintainer but you still suggesting that we, maintainers, >>> should do 2 times more job by supporting several simultaneous Fedora >>> versions instead of 3 right now for more than two years. And that's >>> all just because you think it's a good idea to spend my personal time >>> on the rreleases I'm not using anymore. >> No, I never suggest that. Preview versions have a timelife of 6mo >> instead of 12. >> Stable version have a lifetime of 24mo (12mo for regular updates) >> instead of 12. > Exactly what I'm saying - two times more job. So who's gonna pay us > for the time wasted on supporting distributions we're not using > personally? > > I think you didn't get the maintainers motivation (except those RH > fellows whoi just did the job) - we're doing our part because we're > using Fedora daily. What you're suggesting isn't fun anymore. So > somebody should pay for that. Hum.. It should be some misunderstanding somewhere : For security updates: - First half of the year : 2 versions to maintain (+1 version in dev) => As usual - Second half of the year : 3 versions to maintain (+1 version in dev) => Ok, more work, but definitively not 2 times more For other updates: - First half of the year : 1 version to maintain (+1 in dev) => Less work - Second half of the year : 2 versions to maintain (+1 in dev) => As usual *Regards* Matthieu Gautier -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New release cycle proposal (was Rolling release model philosophy (was ...))
Le 06/11/2012 20:19, Mark Bidewell a écrit : > oddly this looks a lot like the Ubuntu release cycle if you replace > stable with LTS Ubuntu LTS in about 5 years lifetime. Other releases have a lifetime of 18mo. For now, there is 5 maintained ubuntu versions at the same time (the older is from 2008) As far as I understand the fp, this is not what we want to (and can) do. > > The cycle would have to go: stable, preview, preview, stable, and > so on to avoid maintaining more than two releases at a time. > > If it went back and forth between stable and preview, you'd have > three supported releases at once in the second half of year two. > Yes, but I didn't find better ;) This will make a stable release every 1.5 year. It will be complicated to mix with a lifetime of 2 years. And extend the lifetime to 3 years is not a good solution (and will be refused anyway). Matthieu. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
