Krita 3.0.1 Release Process

[Dmitry Kazakov]

On Tue, Aug 16, 2016 at 10:58 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> I still fail to see why we had all this panic. It was a storm in a teacup
> sort
> of thing.


Because we do the same mistakes again and again! For how long?!

Today you made one more release and, again, forgot the things we were
discussing on the hangouts, because you continue holding that checklist in
your head! I cannot blame you for forgetting things, everybody does it, but
you don't even want to see a problem in it!

When discussing on hangouts we ended up with a checklist [1] that includes
"Update the krita.rc version number" on every release. You yourself wrote
this line, and we all agreed with it. And now you tell me on IRC that we
shouldn't update the version each time, instead the developers should
update it when committing patches. Now I ask, why the hell we spent an hour
of our lives on discussing stuff on Hangouts if we don't follow what we
agreed upon?

Yes, everyone can forget the stuff. I can forget things, you can forget
things. To avoid this one should write the stuff anywhere and follow what
is written. Why you refuse to just write down our process anywhere?

[1] -
https://community.kde.org/Krita/Release/Checklist_Krita_Release_Checklist




> What exactly went wrong? Only one thing, the feature-freeze mail wasn't
> cc'ed to the docs mailing list. Well, when we had our release checklist
> skype
> call that wasn't even mentioned. Now we know, and it can be fixed.
>

Ok, now we know, and where it is written? Where is the guarantee that we
will not forget about it the next time? Do you plan to keep it in your head
again? That is the problem I'm talking about.



> I do not want to make changes even before we've had one cycle to learn
> from. We
> already have a system that sends the mails; we don't need another one. We
> already
> have a checklist, and it's a nice and short one:
>

No, it is a wrong one! You invented it while writing instead of just using
the checklist we agreed upon [1].


There is nothing going on in my head apart from these things.
>

Please remember that you have other people in a team that should take part
in the release process as well. E.g. publish announcements when you do the
builds or push the translations or bugfixes from the local copy to SVN
before you do the builds.



> What I need help with is not small things like setting version numbers. I
> need
> people who can
>
> a) make the source release the right way (no volunteers, and Cyrille
> appears
> not to be around, so that's my task for today...)
> b) prepare the binaries -- also the right way (i.e., not with macports or
> so on OSX and not with MSVC on Windows, improvements to the way I do this,
> for instance by signing the binaries are welcome, of course). (And I need
> to fix the Windows binaries today...)
>

Until there are explicit tasks with it, noone will be able to help you with
it.


I also think that if there are problems with the translators they shouldn't
> be
> bothering you, but write the mailing list directly. Or contact me, but even
> better, they should assign a coordinator who can inteface between us and
> the
> translation community.
>

The problem is not in translators but in the fact that we have no release
plan that everybody can see and follow.


Boud, speaking truly, I don't understand why you constantly refuse to
automate the process anywhere. Just login to Trello, take the tasks you
want to do and assign the rest of tasks to other people. Add/Remove tasks
you don't think are ok for the current release. If you want to change the
release schedule, just change it, and people we see it automatically! They
will not have to sit on IRC all day long just to get a notification when
you do the package. Is it that difficult? Does it take so much time?

If we modify the process, we can modify it right in Trello. And when we
start the next iteration in September, we will just copy entire board and
have all the changes we did! Is it that difficult?


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160816/b495ebae/attachment.html>