hecks and comments the small issues, the review by the human
reviewer naturally focuses on more high-level questions.
--
Cornelius Schumacher
ason why we should consciously decide
what our target is. It might be perfectly valid to focus on current
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
ould review our position, 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
o the people who can.
Regards,
Cornelius
--
Cornelius Schumacher
ganized stuff, which
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
ave http://wiki.kde.org/, which is meant to serve this
information. Maybe we need to just improve this or make it more accessible.
--
Cornelius Schumacher
lease management,
translations, packaging, beta testing and all the other things which need to
happen around a release.
--
Cornelius Schumacher
elease
process of increased agility. The first we have in our hands, the second is
something where we need to team up with distributions.
--
Cornelius Schumacher
rs, and it's really
not the atmosphere, I'd like to see in KDE.
--
Cornelius Schumacher
In general it's a good idea to do a "git pull --rebase", when pulling as this
doesn't create merge commits with local changes, which can clutter up the
history.
--
Cornelius Schumacher
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
ly do that now. Any takers for augmenting the examples with step-by-step
instructions from the real world?
--
Cornelius Schumacher
, which is non-trivial
to integrate, otherwise a consistently working and stable master is impossible
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
nce, but hopefully the model proves to be strong enough to
accommodate our needs for stability as well as rapid bug fixing of new code.
--
Cornelius Schumacher
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
iscussed. I'm looking forward 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
ets like that.
I don't think we can talk about a plan yet. This started as brainstorming and
some ideas, and an idea for something like a big hairy goal. I would love to
see this evolve into an actual plan for the future, but there certainly is a
lot of work ahead, before we are there.
--
Cornelius Schumacher
an important part of what makes KDE? I mean, if
> developers decided to make KDE 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
On Saturday 30 October 2010 Stephen Kelly wrote:
> Answering Cornelius and Alexander here.
>
> Cornelius Schumacher wrote:
> > I know what you think ("madness", "no", "KDE 5", "impossible",
> > "governance", "binary comp
19 matches
Mail list logo
