/usrmove? -> about the future

Reindl Harald h.reindl at thelounge.net
Fri Feb 10 15:43:07 UTC 2012



Am 10.02.2012 16:06, schrieb Peter Hutterer:
> On Fri, Feb 10, 2012 at 01:13:13PM +0100, Reindl Harald wrote:
>> POSSIBLE SOLUTION:
>>
>> each second release does not introduzce those big changes and
>> only optimize existing things and bringing only new versions
>> of packages require a "simple" mass rebuild for so-changes
>>
>> you can call it F17, F17.5 where F17 have a big chnage affecting
>> the whole distribution and F17.5 is "only" a careful upgrade
>> without intention to break stuff and require actions from
>> all involved people
>>
>> take away the current pressure from maintainers as well users
>> give the involved people time to breath
>> this is opensource, there is NO SINGLE NEED to implement any
>> possible good idea under pressure NOW and beeing first only
>> for beeing first is not always the right hting
> 
> I think this would increase the pressure to push unpolished features into
> the distribution. Allowing big feature changes only every two releases means
> that the waiting time should the feature not get merged is 12 months.
> For some features that's quite unacceptable.
> 
> So the likely effect is that these features will be called ready whenever
> they need to be (according to the process) with the rest simply called
> "optimizing".

if people do not care the can destroy every process
if someone calls repeatly non-ready features as ready
he is the wrong person for any sort of decision

maybe the project should get rid of some people who
do not care or guidelines which have the power to
ENFORCE contributors or get rid of them

yes this may sound hard
but what is the alternative?

burn down ressources with each relese more and more

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120210/6cdf753e/attachment-0001.sig>


More information about the devel mailing list