[prev in list] [next in list] [prev in thread] [next in thread] 

List:       owncloud
Subject:    Re: [owncloud-user] ownCloud Client Version 2.2.2 Released
From:       Andrea Croci <andrea.croci () gmx ! de>
Date:       2016-07-04 14:03:30
Message-ID: dc104b4b-cc84-16d2-9479-904f96723ee3 () gmx ! de
[Download RAW message or body]

Hello People,

I believe the distros should keep packaging their things whenever they =

deem fit, without pressure for being quicker. The have a reason for =

doing that. People like me, who are paranoid and always want to have the =

newest version of everything, can take their own risk and add the ppas. =

That way everybody is happy. This only applies to Linux, obviously.

Regarding beta testing, I would be happy to help, if there is a ppa from =

where I can pull the RCs and betas (unless I'm already doing it without =

knowing it). However I probably would not be the best beta tester, =

because I don't use all the functions and because I'm not technically =

very versed. Still, if I can be of help, I will because you guys are =

doing such an amazing job, that really deserves support by everybody who =

can.

Regards,

Andrea.

On 04.07.2016 15:08, Klaas Freitag wrote:
> On 30.06.2016 00:55, Sandro Knau=DF wrote:
> Hi Sandro,
>
>>> But maybe, next time we screw, drop a short note please. Danimo has
>>> enabled the updater for 2.2.2 - happy updating :-)
>>
>> And keep in mind, there are also distribution that build the ooc for =

>> their
>> users - If you think that version are screwed up, than this is a very
>> interesting information for distribution. Normally you guys complain =

>> ditros to
>> be "slow" in making the release ready for the users. But yourself do =

>> not trust
>> the released version and wait also some time before giving it to =

>> everybody.
>
> It is not a question of "trust" and intention and all these big words. =

> We just saw that 2.2.0 and unfortunately 2.2.1 were troublesome, and =

> held them back. It was not a super critical problem, nor something we =

> could not have talked about. Most people did not even realize.
>
> Needless to say that this was a huge pitty.
>
>> With the information in this thread I see that the attitude to try to =

>> build
>> the new version as fast as possible will maybe result in bad user =

>> experience -
>> So I really should change the packaging process for debian and wait =

>> some weeks
>> after release date before even think about starting packaging to be =

>> sure, that
>> the version is not screwed up. Is that what you want?
> No, absolutely not. We are working hard to make every release very =

> good from day one. The incident I was talking about before was an =

> exception and not something we calculate or even accept.
>
>> Okay the text is polemic I know - but I really think, that hiding the
>> information that a version is screwed up is not a good idea, because =

>> this will
>> trigger problems downstream. F.ex. I have packaged 2.2.0 and 2.2.1 =

>> for debian
>> already, but not 2.2.2 because form the changelog it sounds like =

>> "okay some
>> bugs are closed" -> will do the packaging, when I have time for. With =

>> the
>> information at this thread I now know, okay I should package 2.2.2 =

>> faster,
>> because 2.2.0 and 2.2.1 are screwed up. ( Or better wait for 2.2.3 ?)...
>
> It was not that the information was hid. There was no intention behind =

> not telling. It was a fail of certain people (lets say me), happening =

> in the hardest time of the project so far. And please remember that we =

> talk about enabling of the auto updater here, which is disabled in =

> Debian anyway, right?
>
> The version was not so bad that we had to pull it or such. Please do =

> not overdo it.
>
> But what does all this tell us: We need to communicate all this. Ok, I =

> apologize again for not doing it.
>
> But honestly, our biggest problem that is the root of this is that the =

> pre-releases (betas and RCs) are only rarely tested in the community. =

> I would be happy to learn why not. If that remains that way, that will =

> probably force us to a different release procedure, which I would find =

> confusing.
>
> regards,
>
> Klaas
>
>
> _______________________________________________
> User mailing list
> User@owncloud.org
> http://mailman.owncloud.org/mailman/listinfo/user

_______________________________________________
User mailing list
User@owncloud.org
http://mailman.owncloud.org/mailman/listinfo/user
[prev in list] [next in list] [prev in thread] [next in thread]