issues, the review by the human
reviewer naturally focuses on more high-level questions.
--
Cornelius Schumacher schumac...@kde.org
, and make sure that we know why we
are not going with the flow, and why we are paying the price of a higher
barrier of entry and the additional effort of hosting our own infrastructure.
--
Cornelius Schumacher schumac...@kde.org
contributors and go with something like a gerrit-based solution, but if we
want to focus on new people there might be better solutions.
[1]: https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html
--
Cornelius Schumacher schumac...@kde.org
is only understandable, if you have inside knowledge, to 3rd parties as
documentation.
Techbase is supposed this organized documentation understandable by 3rd
parties, so only the stuff, which fits this should go there.
--
Cornelius Schumacher schumac...@kde.org
this
information. Maybe we need to just improve this or make it more accessible.
--
Cornelius Schumacher schumac...@kde.org
. The first we have in our hands, the second is
something where we need to team up with distributions.
--
Cornelius Schumacher schumac...@kde.org
,
translations, packaging, beta testing and all the other things which need to
happen around a release.
--
Cornelius Schumacher schumac...@kde.org
in KDE.
--
Cornelius Schumacher schumac...@kde.org
to achieve.
The same for releasing. We need branches for that, so that master can continue
to get feature development, while a branch is hardened for release.
--
Cornelius Schumacher schumac...@kde.org
takers for augmenting the examples with step-by-step
instructions from the real world?
--
Cornelius Schumacher schumac...@kde.org
On Thursday 09 June 2011 David Jarvie wrote:
In order to get good testing coverage, there should normally only be one
integration branch per git module. Otherwise, testing coverage will be
split between the competing integration branches.
Right.
--
Cornelius Schumacher schumac...@kde.org
pull --rebase, when pulling as this
doesn't create merge commits with local changes, which can clutter up the
history.
--
Cornelius Schumacher schumac...@kde.org
it to be a reasonable
fit for as many people as possible. Obviously we'll have to see how well it
works and adapt it, if necessary, but it should be a good start.
--
Cornelius Schumacher schumac...@kde.org
to the upcoming face-to-face
meetings, but we should also have a wider discussion, as this is affecting
many more people than those who will have the opportunity to be at these
meetings.
--
Cornelius Schumacher schumac...@kde.org
apps, isn't it sometimes
because KDE libraries rock?
Exactly. So if these rocking libraries are part of Qt and so available to
every single Qt developer, they can easily become part of KDE as well.
Something which is quite a barrier today.
--
Cornelius Schumacher schumac...@kde.org
15 matches
Mail list logo
