[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: alpha/beta software in Fedora 8?



On 11/29/2007 10:23 AM, Matej Cepl wrote:
On Wed, 28 Nov 2007 15:45:31 +0100, Christopher Aillon scripst:

On 11/28/2007 01:55 PM, Jesse Keating wrote:
On Wed, 28 Nov 2007 07:46:53 -0500
"Tom \"spot\" Callaway" <tcallawa redhat com> wrote:

Well, I'm not sure how it can be considered perfect when it does not
begin to address the "alpha/beta" issue that you think is resolvable
with packaging policy.
"In general, it is preferred if maintainers avoid releasing "alpha" or
"beta" builds of packages into Fedora (both Rawhide and released
updates).  However a package maintainer has the right to use their own
discretion regarding this issue and may provide whatever (s)he sees fit
for the user base.  Things to consider include the amount of testing an
alpha or beta release has seen, the timeline to turn said alpha or beta
into a stable release, the feature sets provided, or the bugs fixed.
There may be other factors at play as well, which is why the person
best suited to make such a decision is the package maintainer in
question."
This would also work.  Just so a maintainer can figure out what general
path they should be following in a release.  /me likes.

I think this is the way to hell -- we will be writing long and longer legalese which won't mean much more than "Don't be stupid and test your packages".


If we want to empower maintainers to be able to MAKE (good) decisions, we MUST give them some guidelines. Making decisions is the reason WHY we have maintainers. Else, we could just script blindly following upstream. And THAT would be real hell.

This is not trying to BIND[*] maintainers to anything. This is trying to EDUCATE as to what sorts of things they should be looking for so they are able to execute their judgements. Call it guidelines, suggestions, hints, policy, whatever. That's all pedantry. But if we are able to give maintainers some help on making more decisions, it will be more rewarding for the maintainer and everyone involved.

[*] Pun not really intended, noticed on second reading of it.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]