Re: State of Proposal to improving KDE Software Repository Organization?
On Tue, Jan 19, 2016 at 7:28 AM, Friedrich W. H. Kossebau
wrote:
> Hi,
Hi,
>
> (calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
> please remove from reply, discussion only on kde-core-devel should be fine)
>
> 4 months ago there was the thread "Proposal to improving KDE Software
> Repository Organization" on this mailinglist.
> What happened to that plan? Are people preparing its execution?
That plan is tied up in other things taking priority / lack of time / etc.
We'll get there eventually. It is also in part related to the Phabricator move.
>
> And would that be a time where some bigger reorganization of the repos is
> possible?
>
> Reason that I ask is that due to the split of Calligra into several repos (see
> background^) the layout in the repo structure does no longer properly reflect
> the project organisation. Right now there are three active repos in the
> calligra/ repo substructure:
> "calligra" at "calligra/"
> "krita"at "calligra/krita"
> "kexi" at "calligra/kexi"
>
> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to
> mpyne about if moving it to "calligra/calligra" should fix it.))
Repositories within repositories is a known bad thing to do, the
systems don't handle it properly at all (as it was never an intended
thing you should do). The proper fix is to move the repo to
calligra/calligra (ie. have a "calligra/" top level grouping project).
>
> Things that are not properly matching organization:
> * Krita starting with 3.* no longer is part of Calligra project
> (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
> what people think to which project Krita belongs)
> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
> so no reason to be in a complete own toplevel structure,
> rather should be in the same sub structure, i.e. "Extragear",
> like extragear/calligra/* and extragear/graphics/krita
In the Phabricator world I had envisioned Extragear as no longer existing.
>
> More, not only Calligra & Krita related:
> * "Extragear" is an awful grouping name for apps with individual
> release plans, a legacy term that no longer fits most of the apps
> in that substructure
> * "KDE Applications" is a misleading grouping name for apps with a
> central release plan, as if those with individual release plans
> are not "KDE" applications (as in, not done in the KDE community)
> * a single category per app as needed by the current tree structure layout
> of the repos, like "office", "graphics", "utils", is rather awkward,
> many apps do not match exactly one or would match multiple categories
Phabricator will allow multiple "categories" to be tagged to a repository...
>
> So IMHO some update of the repository organisation would be good, to reflect
> how things are these days.
> Renaming of "Extragear" and "KDE Applications" is surely something which needs
> care from promo/marketing/VDG people first to find if that makes sense at all
> and what a good solution would be.
Extragear is really an internal structure, not part of marketing so I
think we can go ahead and just kill it...
> (Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
> maintainer of Calligra, which is not, but still done in the very same KDE
> community, that current naming seems so wrong to me).
>
> But the actual names and grouping aside, for the pure technical renewing
> (which also involves all infrastructure like translation system,
> documentation, phabricator, etc), who is currently planning or working on
> what?
Like most things in this department, Sysadmin...
> So does it makes sense to wait some more, or should we assume the current
> organization stays for longer, and Calligra & Krita repos should be moved
> inside that organization for now?
Not sure how long things are going to take sorry.
Chances are the existing tree will survive in some form (even if it is
only in the XML file various things use) so you may as well do it now.
>
>
> ^Some background about Calligra repo split, as things are slightly
> complicated:
>
> KRITA) The "krita" repo was split off, because Krita has finally become a
> full project of its own, separate from Calligra. A logical place for the krita
> repo in the KDE repo structure would perhaps have been somewhere in extragear,
> but at least due to the translators preferring to keep the string catalogs of
> Krita in the "calligra" module as before, for less work, the krita repo was
> for now put as submodule of "calligra/".
>
> KEXI) Kexi continues to be part of the Calligra project/subcommunity, but the
> Kexi developers preferred a small simple repo "kexi" of their own (for build
> time and size). So the placement at "calligra/kexi" makes perfect sense.
>
> OTHERAPPS) As the other Calligra apps (Braindump, Karbon, Sheets, Words,
> Stage, etc.) are more tightly coupled and the binary interfaces between libs,
> plugins & apps can still change e
Re: State of Proposal to improving KDE Software Repository Organization?
On Tue, Jan 19, 2016 at 8:27 AM, Boudewijn Rempt wrote:
> On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:
>
>> Reason that I ask is that due to the split of Calligra into several repos
>> (see background^) the layout in the repo structure does no longer properly
>> reflect the project organisation. Right now there are three active repos in
>> the calligra/ repo substructure:
>> "calligra" at "calligra/"
>> "krita"at "calligra/krita"
>> "kexi" at "calligra/kexi"
>
>
> What I'm wondering is, where is this "structure" actually visible? Not in
>
> https://quickgit.kde.org/
Quickgit shows the raw git repository structure, which deliberately
does not include the tree in it.
>
> or
>
> https://phabricator.kde.org/diffusion/
Eventually we'll have projects for each broader category (Multimedia,
Graphics, etc) and repositories will be tagged for those.
Phabricator will never provide a repository tree though (nor should
it, the existing tree is a hell of a maintenance nightmare).
>
> I see it reflected in the old, to be discarded
>
> https://projects.kde.org/projects
>
> But where else? And what is it actually needed for?
The build metadata depends on it, and it is used by:
- The CI system
- API / LXR / EBN
- Scripty.
- kdesrc-build
>
>>
>> (("calligra" at "calligra/" confuses at least kdesrc-build, sent an email
>> to mpyne about if moving it to "calligra/calligra" should fix it.))
>>
>> Things that are not properly matching organization:
>> * Krita starting with 3.* no longer is part of Calligra project
>> (screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
>> what people think to which project Krita belongs)
>> * Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
>> so no reason to be in a complete own toplevel structure,
>> rather should be in the same sub structure, i.e. "Extragear",
>> like extragear/calligra/* and extragear/graphics/krita
>>
>> More, not only Calligra & Krita related:
>> * "Extragear" is an awful grouping name for apps with individual
>> release plans, a legacy term that no longer fits most of the apps
>> in that substructure
>
>
> It's ghastly -- almost insulting. It's perpetuating the fallacy that
> there are core KDE projects and peripheral projects.
I agree. Which is why i'd like to see the Extragear moniker dropped.
If repositories are part of some broader release unit (like KDE
Applications - even if this does have a better name) then they still
need to visible as belonging to it though I think.
>
>> * "KDE Applications" is a misleading grouping name for apps with a
>> central release plan, as if those with individual release plans
>> are not "KDE" applications (as in, not done in the KDE community)
>
>
> Horrible as well.
>
>> * a single category per app as needed by the current tree structure layout
>> of the repos, like "office", "graphics", "utils", is rather awkward,
>> many apps do not match exactly one or would match multiple categories
>
>
> Honestly, the need to group repositories is, to me, so weird that I think it
> would be best to adopt the following scheme:
Note that "Frameworks", "KDevelop" and "KDE Telepathy" are all fairly
logical groupings of repositories (and things would be completely
unmanagable in so many ways if we didn't have these).
>
> a/amarok
> a/...
> ...
> c/calligra
> g/gcompris
> k/krita
>
> And so on. It's meaningless as it is; it would be better to make that clear,
> if grouping is really needed.
>
>> So IMHO some update of the repository organisation would be good, to
>> reflect how things are these days.
>> Renaming of "Extragear" and "KDE Applications" is surely something which
>> needs care from promo/marketing/VDG people first to find if that makes sense
>> at all and what a good solution would be.
>
>
> That again begs the question: where is the "organization" which apparently
> has
> purely technical reasons visible to contributors and users?
>
>> (Being both maintainer of Okteta, which is in "KDE Applications", and
>> meta-co-
>> maintainer of Calligra, which is not, but still done in the very same KDE
>> community, that current naming seems so wrong to me).
>>
>> But the actual names and grouping aside, for the pure technical renewing
>> (which also involves all infrastructure like translation system,
>> documentation, phabricator, etc), who is currently planning or working on
>> what?
>> So does it makes sense to wait some more, or should we assume the current
>> organization stays for longer, and Calligra & Krita repos should be moved
>> inside that organization for now?
>>
>>
>> ^Some background about Calligra repo split, as things are slightly
>> complicated:
>>
>> KRITA) The "krita" repo was split off, because Krita has finally become a
>> full project of its own, separate from Calligra. A logical place for the
>> krita repo in the KDE repo structure would perhaps have been somewhere in
>> extragear, but at least due to the translators preferring to keep the string
>> cata
Re: Review Request 126797: Add kexi.git build with deps
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126797/#review91297 --- Ship it! This is fine, please go ahead and commit. - Ben Cooksley On Jan. 18, 2016, 6:42 p.m., Jarosław Staniek wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126797/ > --- > > (Updated Jan. 18, 2016, 6:42 p.m.) > > > Review request for Calligra and Ben Cooksley. > > > Repository: kde-build-metadata > > > Description > --- > > Add kexi.git build with deps, minor updates to kexi's deps > > > Diffs > - > > dependency-data-kf5-minimum 95dad0d > dependency-data-kf5-qt5 3856fe3 > logical-module-structure 061ca5f > > Diff: https://git.reviewboard.kde.org/r/126797/diff/ > > > Testing > --- > > no > > > Thanks, > > Jarosław Staniek > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Calligra - FTBFS - due to VC?
Hi Calligra Developers, It appears Calligra currently fails to build on the CI system, due to ifdef's which are dependent on VC variables. This is despite VC being found (depending on a too new / too old version / missing an include?) Please see https://build.kde.org/view/branchGroup%20kf5-qt5/job/calligra%20master%20kf5-qt5/5/PLATFORM=Linux,compiler=gcc/consoleFull Could someone take a look and fix it please? Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra - FTBFS - due to VC?
On Tue, Mar 29, 2016 at 11:46 AM, Friedrich W. H. Kossebau wrote: > Am Dienstag, 29. März 2016, 11:36:18 CEST schrieb Ben Cooksley: >> Hi Calligra Developers, >> >> It appears Calligra currently fails to build on the CI system, due to >> ifdef's which are dependent on VC variables. This is despite VC being >> found (depending on a too new / too old version / missing an include?) >> >> Please see >> https://build.kde.org/view/branchGroup%20kf5-qt5/job/calligra%20master%20kf >> 5-qt5/5/PLATFORM=Linux,compiler=gcc/consoleFull >> >> Could someone take a look and fix it please? > > Seems CI uses Vc 1.2 for qt5/kf5 stable builds and even Vc master for master > kf5-qt5. > Was that done by requests of Krita devs? Which would be fine, just needs > Calligra to follow any changes needed then. Not sure who would have requested it unfortunately. Scarlett might know more there. Is this an issue for Calligra? (the versions in use that is) > > Though current Krita builds seems to be done without Vc being installed as > dep, so cannot tell by that: > https://build.kde.org/job/krita%20master%20kf5-qt5/3/ > PLATFORM=Linux,Variation=All,compiler=gcc/consoleText Probably needs an update to the build metadata - which I suspect may not have been done since Krita moved to it's own repo. > > Cheers > Friedrich Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra - FTBFS - due to VC?
On Tue, Mar 29, 2016 at 9:53 PM, Friedrich W. H. Kossebau wrote: > Am Dienstag, 29. März 2016, 07:27:07 CEST schrieb Boudewijn Rempt: >> For Krita, and so I guess for Calligra as well, the right version is 0.7. >> Thorsten Zachmann is working on the port to 1.2, but he hasn't pushed >> anything yet. > > Okay. > > So translated in some tasks for changing settings on CI for now (as I assume > those settings are admin-only, nothing normal developers can help with, > right?) > > Please see > https://phabricator.kde.org/T1992 (use only 0.7.* with any Vc builds) > https://phabricator.kde.org/T1993 (use "qt4" build of Vc as dep for Calligra > Qt4 build) > https://phabricator.kde.org/T1994 (add Vc as build dep to krita build) Thanks, i've begun actioning the necessary changes. > > Cheers > Friedrich > Regards, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kdiagram in calligra project component?
Hi, Sorry, I don't see what I need to answer here? Cheers, Ben
Re: Please cleanup your scratch and clone repositories
On Sat, Nov 26, 2016 at 7:53 AM, Ben Cooksley wrote: > Hi all, Hi all, > > To help Sysadmin assess how these types of repositories would be used > under Phabricator, it would be appreciated if everyone could please > cleanup the scratch and clone repositories they're no longer using and > have no need to keep. > > You can get a list of repositories you have by visiting > https://cgit.kde.org/ or by running the below command and filtering > appropriately using your favourite tools. > > ssh g...@git.kde.org info > > Once you've determined the repositories to remove, they can be removed > by running the following two commands: > > ssh g...@git.kde.org D unlock scratch/username/reponame > ssh g...@git.kde.org D rm scratch/username/reponame > > Please note that the trailing .git should not be included, otherwise > the system will not accept your request. You can substitute > scratch/... for clones/... as appropriate here. > > Thanks in advance for removing unused repos! We've had good progress so far in cleaning up unused repositories - i'd estimate good 50 or so repositories have been cleaned up. For those who haven't yet checked their personal clones and scratch repositories it would be appreciated if you could do so. > > Regards, > Ben Cooksley > KDE Sysadmin Thanks, Ben Cooksley
Phabricator: All repositories registered - upcoming workflow changes
Hi everyone, We've just completed the registration of all mainline repositories (not including Websites or Sysadmin namespaced ones) on Phabricator. Thanks go to Luigi Toscano for providing significant assistance with this process. >From this point forward, communities should be moving away from Reviewboard to Phabricator for conducting code review. Sysadmin will be announcing a timeline for the shutdown of Reviewboard in the near future. Projects which haven't yet looked into Phabricator, including getting things like mailing list notifications and projects setup should do so as soon as practical. As part of the registration process, Sysadmin tagged repositories, associating them to Projects. These tags show what a repository is associated with and it's status. This includes things like whether development is currently active (the Historical Archival and Up For Adoption tags), which release unit it is part of (KDE Applications, Frameworks, etc) and the general development effort it is associated with. It would be appreciated if everyone could please check their repositories to ensure they've been tagged correctly. Adjustments can either be sent as replies to this email (include sysadmin@ in CC please) or by asking a member of the Community Admins project on Phabricator to make the change for you. Thanks, Ben Cooksley KDE Sysadmin
Re: Phabricator: All repositories registered - upcoming workflow changes
On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin wrote: > On Sunday January 29 2017 08:32:21 Ben Cooksley wrote: > > Hi, Hi Rene, > > >From this point forward, communities should be moving away from >>Reviewboard to Phabricator for conducting code review. Sysadmin will >>be announcing a timeline for the shutdown of Reviewboard in the near >>future. > > I hope that shutdown doesn't mean complete disconnect; it would probably be a > loss of as-yet unknown importance if all code reviews become unavailable. > > I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, but > RB had its advantages too which could be why it's still being used (quite a > lot, as far as I can see) and hasn't been integrated with KDE's own IDE yet. It will be a complete shutdown of Reviewboard - we'll be archiving it in the event for some reason it becomes necessary to access the data it stores. In most cases mailing lists should have the history of reviews in their archives, so those will continue to be accessible through list archives in the long run. > > R. Cheers, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
On Wed, Feb 1, 2017 at 8:10 AM, Luigi Toscano wrote: > Ben Cooksley ha scritto: >> On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin >> wrote: >>> On Sunday January 29 2017 08:32:21 Ben Cooksley wrote: >>> >>> Hi, >> >> Hi Rene, >> >>> >>> >From this point forward, communities should be moving away from >>>> Reviewboard to Phabricator for conducting code review. Sysadmin will >>>> be announcing a timeline for the shutdown of Reviewboard in the near >>>> future. >>> >>> I hope that shutdown doesn't mean complete disconnect; it would probably be >>> a loss of as-yet unknown importance if all code reviews become unavailable. >>> >>> I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, but >>> RB had its advantages too which could be why it's still being used (quite a >>> lot, as far as I can see) and hasn't been integrated with KDE's own IDE yet. >> >> It will be a complete shutdown of Reviewboard - we'll be archiving it >> in the event for some reason it becomes necessary to access the data >> it stores. > > Isn't it a way to change the site in static website and keep it alive? > Checking the history of a review can tell a lot. Also for discarded reviews. While I have yet to test it, Reviewboard does use quite a bit of AJAX and other dynamic resources - so I won't be surprised to find out that the usual mechanisms for creating static copies of sites don't produce a workable result. > >> >> In most cases mailing lists should have the history of reviews in >> their archives, so those will continue to be accessible through list >> archives in the long run. > > I think we should ensure to have the archives on mail.kde.org if this is the > case. Unfortunately a number of lists have their archiving disabled - so we'll need archives from a member of the community to re-seed the server copies (this was a historical decision, taken before KDE 3 even existed I suspect). > > > -- > Luigi Regards, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
On Wed, Feb 1, 2017 at 9:26 PM, René J.V. Bertin wrote: > On Wednesday February 1 2017 20:59:46 Ben Cooksley wrote: > > Hi > >> >>While I have yet to test it, Reviewboard does use quite a bit of AJAX >>and other dynamic resources - so I won't be surprised to find out that >>the usual mechanisms for creating static copies of sites don't produce >>a workable result. > > Hmmm, I think one doesn't need to be logged in in order to consult and > download things, correct? If so, disabling authentication is all that's > needed to make the site read-only. We'd still have to keep the software running, and up to date (to avoid it becoming a security risk). I'd prefer to optimise our resources towards keeping what we are actively using in the best condition, rather than having to remain concerned with keeping legacy systems running for purely archival purposes. We have a significant amount of systems already (and associated technical debt in some instances). Let's not make the problem any worse please. > > R. Cheers, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
On 1/02/2017 10:38 PM, "René J.V. Bertin" wrote: On Wednesday February 1 2017 22:16:50 Ben Cooksley wrote: >We'd still have to keep the software running, and up to date (to avoid >it becoming a security risk). Running yes, but if log-in is disabled at the core and not linked to the central LDAP service or whatever it is you use, what significant security risk could it pose? I don't have the impression the software has been upgraded that frequently but I haven't been monitoring that either. It gets upgraded, particularly when there is a security advisory. Most Reviewboard updates don't make user visible changes though - they're minor bug fix updates. Reviewboard would still be running on the server - and all the issues that come with that. >I'd prefer to optimise our resources towards keeping what we are >actively using in the best condition, rather than having to remain >concerned with keeping legacy systems running for purely archival >purposes. > >We have a significant amount of systems already (and associated >technical debt in some instances). Let's not make the problem any >worse please. I guess it depends on the importance you attach on being able to retrieve things from revision and review histories. That's not to say it should be kept around online forever, but I'd say 2 years is a reasonable time to keep providing read-only access before archiving and taking everything offline for good. I'd offer to help during that period but without any experience with the associated kind of sysadminship I'm not convinced that would be of much value. I take it you investigated whether there is any existing way to transfer existing records from ReviewBoard to Phabricator? That would make the whole issue moot. Migrating things, particularly line by line comments, was too difficult compared to the benefit provided. R. Regards, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
On 2/02/2017 12:41 AM, "Luigi Toscano" wrote: On Wednesday, 1 February 2017 10:31:44 CET Francis Herne wrote: > Sorry, forgot to reply-all and only sent to kdevelop-devel... > > - > > Hi, > > First off, there's a lot of postponed, or at least possibly-useful, > work on ReviewBoard which would be lost. Some of this is from newish > contributors who might be discouraged - e.g. the author of > https://git.reviewboard.kde.org/r/129589/ mentioned on IRC the other > day that he's hoping to complete it at some point. I think that we need some cleanup on the old reviews (Albert Astal Cid started some time ago) and more important strongly tell new users (and old users) to use Phabricator. I don't think that anyone wants to lose the work, but if a review has not been touched in a few months maybe it's time to see it is still interesting. If we start doing this now (or yesterday), the flow of new patches in reviewboard should decrease quickly. Getting everyone to shift over was the whole point of this thread. No new reviews should be opened on ReviewBoard, and existing ones shouldnt take more than a few weeks to clear. Anything older than that usually won't apply to the code anymore. > For already-committed work: > > Even if the mail-archiving infrastructure was in a useful state, this > would be inconvenient - there are more than a *thousand* REVIEW: tags in > kdev* project commits, plus several comments with "see ". > > Many mailing lists aren't logged at all, there's no internal > search with only patchy Google indexing, and 'browsing' the archive > means clicking through arbitrarily-grouped mails by date with minimal > threading. That's not merely inconvenient, it's going to cause a > catastrophic loss of information. I agree as well that the review information should be kept online. -- Luigi Regards, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
On Wed, Feb 1, 2017 at 9:48 PM, Milian Wolff wrote: > On Tuesday, January 31, 2017 7:56:52 PM CET Ben Cooksley wrote: >> On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin > wrote: >> > On Sunday January 29 2017 08:32:21 Ben Cooksley wrote: >> > >> > Hi, >> >> Hi Rene, >> >> > >From this point forward, communities should be moving away from >> >> >> >>Reviewboard to Phabricator for conducting code review. Sysadmin will >> >>be announcing a timeline for the shutdown of Reviewboard in the near >> >>future. >> >> >> > I hope that shutdown doesn't mean complete disconnect; it would probably >> > be a loss of as-yet unknown importance if all code reviews become >> > unavailable. >> > >> > I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, >> > but RB had its advantages too which could be why it's still being used >> > (quite a lot, as far as I can see) and hasn't been integrated with KDE's >> > own IDE yet. >> >> It will be a complete shutdown of Reviewboard - we'll be archiving it >> in the event for some reason it becomes necessary to access the data >> it stores. > > This is a *very* bad idea! > > - Quite some commits will lose some extended history from the review comments > - What about the not-yet-merged changes? There will sufficient time between now and when the shutdown is actually actioned during which it's expected any remaining reviews can either be finished off, or moved to Phabricator (As said in my original mail, we'll be publishing a timeline for this - which will have stages where no new reviews can be opened, etc) > > If at all possible, please find a way to keep this site alive in a read-only > mode. > >> In most cases mailing lists should have the history of reviews in >> their archives, so those will continue to be accessible through list >> archives in the long run. > > And how do you find the corresponding mail archive thread based on a > reviewboard URL? Will there be auto-forwarding in-place? There won't be any auto-forwarding - we'll be removing the subdomains completely. > > Bye > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Cheers, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
Hi all, As a starting point: keeping the software itself running is a non-starting option from my perspective. It's going to be shutdown. This is purely to reduce the amount of maintenance effort we have to expend in keeping our systems running. There is an enormous amount of software and other systems deployed on our infrastructure, and the value of continuing to maintain software, including associated security updates, major upgrades to ensure we're able to continue running it on modern distributions, etc for something which is no longer in active use is questionable at best. Bitrot and decay is almost guaranteed to erode the value of it as a historical archive in the long run in any case. For those who dismiss decay as an issue - problems with previous Reviewboard upgrades not taking cleanly have resulted in some reviews being damaged, causing their diffs to become unavailable. These sorts of problems do happen. Whether some kind of read only archive is retained is another topic altogether. Reviewboard has a WebAPI which should be usable by anyone interested to extract all the information regarding reviews, including their comments and the diff itself. This could be used to create a static snapshot of each review. Regards, Ben
Re: Phabricator: All repositories registered - upcoming workflow changes
On Fri, Feb 3, 2017 at 11:37 PM, René J.V. Bertin wrote: > On Thursday February 2 2017 21:50:38 Nicolás Alvarez wrote: > >>You missed the point. This "bit rot" is not about disk damage but >>about software incompatibility. ZFS doesn't help with that... > > You mean diffs that no longer apply cleanly? In that case you missed our > point. Being able to consult intermediate versions of diffs, abandoned diffs > etc. is not to be able to apply them "as is". If there were no value in the > kind of code those diffs (can) contain we'd not be using git or git wouldn't > be preserving every single bit of history. Rene, we aren't talking about diffs here. Not even close. What we are talking about is things like silent data corruption caused by upgrade edge cases, database encoding changes and data storage format changes. Not to mention changes in the software stack itself, and our long term ability to keep it running. > > > Oh well. This is just another expression of FOSS's biggest weakness. Every > project has this centre-of-the-universe tendency that apparently justifies > breaking things for large parts of the user base whenever the project feels > it's justified. I'm not even going to respond to that. > > R Regards, Ben
Communication with Phabricator upstream
Hi everyone, Just repeating my last email on this subject as it seems some folks have missed the previous memo. All issues with Phabricator should be logged at https://phabricator.kde.org/tag/phabricator/ - not with upstream. This is being done to avoid duplicate tasks, and to allow us to communicate on a whole of project basis the things we consider important. This helps simplify things for upstream. Thanks, Ben Cooksley KDE Sysadmin
Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes
Hi everyone, This is going to be quite a long email, my apologies in advance for that. If you use the CI system regularly as part of your development flow it is important you read this email in it's entirety as your action will probably be required. If you are aware of a list I have missed in the above, please feel free to forward it there. As some will have been aware of for some time we currently have a problem where changing the system base is an incredibly disruptive activity. We also have issues where builds sometimes fail due to files disappearing mid-build or installations being inconsistent, and excessive numbers of emails are generated. To top this off, everyone has to use the same underlying "base" system for performing builds which sets up conflicts between projects. Oh, and we also only perform CI for Linux. To solve these problems we've been working on a Next Generation CI system which introduces a new concept called 'Products'. In short, a Product is a release unit, such as Frameworks, Plasma, KDE Applications, which groups a series of repositories which are developed and subsequently released together. A preview of this system can be viewed at https://build-sandbox.kde.org/ Products as part of their definition are able to define a set of 'Platforms' on which they build. At the moment we have three Platforms available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7. Adding additional Platforms to this mix is fairly easy, as long as the code can be built there. Qt will now be considered as part of the base system, and is something we will no longer build ourselves. Each Product / Platform definition is fully independent. This will allow for different products to build against different versions of Qt among other things for instance. This is the first part that requires your action: we'd like developers, particularly those whose development relies on bleeding edge system software to assist in creating and maintaining (Linux) Platform images. If you're interested in this, please let me know. As part of the shift to the Products paradigm, a number of changes have been made to how projects are built and dependencies managed. This particularly affects dependencies on projects which are outside your Product (Frameworks is outside of Plasma and Applications for instance). These dependencies will now be satisfied through "Dependency Build" jobs, which will be executed once a week. As a result the master version of Frameworks will no longer be available outside Frameworks itself. This change is one of the big ones which massively reduces the effort required to change base systems and thus hugely improves the maintainability of the CI system. It is therefore quite important and necessary, and also isolates the rest of the CI system from breakages lower down in the stack which have happened in the past. This is the second point that requires your attention. If your development process is dependent on using the latest development version of something which is located in another product, then we will need to add that to your Product. If this affects you, please start a new thread (CC'ing sysadmin and kde-core-devel along with your Product's main list) stating which specific repositories you need and providing one to two lines of explaination for each. Note that requests for the entirety of Frameworks won't be accepted - each must be requested on an individual basis with an explanation given for why your development process is dependent on the master version of that Framework. With the change to Products as a core concept for driving the CI system, this does leave Extragear somewhat in a bit of an unusual situation. At the moment we're planning to deal with this by having Extragear be a 'Product' with all of them combined together. If anyone in Extragear has any comments to make on this they're certainly welcome here. Which brings me to the third point of attention. We'll only be adding projects to the Next Gen CI system at their request going forward. For Frameworks, Applications and Plasma this is something which we're essentially assuming we're going to receive from their release managers, so we'll take care of defining the initial Products for those. For Extragear projects, please respond to this thread if you'd like CI coverage (to continue) to be provided to you. Thanks for all who have reached this point - my apologies again for it's length. Note that the Next Gen system isn't finished yet - Notifications are yet to be setup and there are a few other touches left to be made. Regards, Ben Cooksley KDE Sysadmin
Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes
On Sat, May 6, 2017 at 10:15 PM, Elvis Angelaccio wrote: > On sabato 6 maggio 2017 11:37:51 CEST, Ben Cooksley wrote: >> >> Hi everyone, >> >> This is going to be quite a long email, my apologies in advance for that. >> If you use the CI system regularly as part of your development flow it >> is important you read this email in it's entirety as your action will >> probably be required. If you are aware of a list I have missed in the >> above, please feel free to forward it there. >> >> As some will have been aware of for some time we currently have a >> problem where changing the system base is an incredibly disruptive >> activity. We also have issues where builds sometimes fail due to files >> disappearing mid-build or installations being inconsistent, and >> excessive numbers of emails are generated. To top this off, everyone >> has to use the same underlying "base" system for performing builds >> which sets up conflicts between projects. Oh, and we also only perform >> CI for Linux. >> >> To solve these problems we've been working on a Next Generation CI >> system which introduces a new concept called 'Products'. In short, a >> Product is a release unit, such as Frameworks, Plasma, KDE >> Applications, which groups a series of repositories which are >> developed and subsequently released together. >> >> A preview of this system can be viewed at https://build-sandbox.kde.org/ >> >> Products as part of their definition are able to define a set of >> 'Platforms' on which they build. At the moment we have three Platforms >> available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7. >> Adding additional Platforms to this mix is fairly easy, as long as the >> code can be built there. Qt will now be considered as part of the base >> system, and is something we will no longer build ourselves. >> >> Each Product / Platform definition is fully independent. This will >> allow for different products to build against different versions of Qt >> among other things for instance. >> >> This is the first part that requires your action: we'd like >> developers, particularly those whose development relies on bleeding >> edge system software to assist in creating and maintaining (Linux) >> Platform images. If you're interested in this, please let me know. >> >> As part of the shift to the Products paradigm, a number of changes >> have been made to how projects are built and dependencies managed. >> This particularly affects dependencies on projects which are outside >> your Product (Frameworks is outside of Plasma and Applications for >> instance). These dependencies will now be satisfied through >> "Dependency Build" jobs, which will be executed once a week. As a >> result the master version of Frameworks will no longer be available >> outside Frameworks itself. >> >> This change is one of the big ones which massively reduces the effort >> required to change base systems and thus hugely improves the >> maintainability of the CI system. It is therefore quite important and >> necessary, and also isolates the rest of the CI system from breakages >> lower down in the stack which have happened in the past. >> >> This is the second point that requires your attention. If your >> development process is dependent on using the latest development >> version of something which is located in another product, then we will >> need to add that to your Product. If this affects you, please start a >> new thread (CC'ing sysadmin and kde-core-devel along with your >> Product's main list) stating which specific repositories you need and >> providing one to two lines of explaination for each. >> >> Note that requests for the entirety of Frameworks won't be accepted - >> each must be requested on an individual basis with an explanation >> given for why your development process is dependent on the master >> version of that Framework. >> >> With the change to Products as a core concept for driving the CI >> system, this does leave Extragear somewhat in a bit of an unusual >> situation. At the moment we're planning to deal with this by having >> Extragear be a 'Product' with all of them combined together. If anyone >> in Extragear has any comments to make on this they're certainly >> welcome here. >> >> Which brings me to the third point of attention. We'll only be adding >> projects to the Next Gen CI system at their request going forward. For >> Frame
Retirement of Reviewboard - Transition to Phabricator
Hi all, The following is Sysadmin's suggested plan for the retirement of Reviewboard now that Phabricator is fully up and running for hosting of code reviews. Phase 1: Commences September 2: All repositories are closed for accepting new reviews on Reviewboard. A notice is added to the top of the main page indicating that reviews should now be done on Phabricator. Phase 2: Commences September 16: Login to Reviewboard is disabled, and final backups are taken. A static copy of Reviewboard is generated and published online, and the software itself is taken down. The vast majority of projects should now be migrated to Phabricator, with only historical reviews needing to be cleaned up. Note that due to how Reviewboard stores diffs and reproduces them for use, some reviews may have decayed and may no longer be readable. This is due to short-hashes which are used by Git/Reviewboard in diffs now having collisions with other commits which previously did not exist. Unfortunately there is nothing we can do about this. Any comments on the above? Regards, Ben
Re: Retirement of Reviewboard - Transition to Phabricator
On 25/08/2017 5:41 AM, "Albert Astals Cid" wrote: El dijous, 24 d’agost de 2017, a les 21:07:49 CEST, Ben Cooksley va escriure: > Hi all, > > The following is Sysadmin's suggested plan for the retirement of > Reviewboard now that Phabricator is fully up and running for hosting > of code reviews. > > Phase 1: Commences September 2: All repositories are closed for > accepting new reviews on Reviewboard. A notice is added to the top of > the main page indicating that reviews should now be done on > Phabricator. > > Phase 2: Commences September 16: Login to Reviewboard is disabled, and > final backups are taken. A static copy of Reviewboard is generated and > published online, and the software itself is taken down. Does this mean i can still see: * Diffs * emails of the people that made those diffs Diffs should definitely be - as long as they're not broken due to the issue I noted. As you wouldn't be able to access them currently there is no change in that regard. In terms of email addresses this will only be the case if Reviewboard displays them publicly. Their username will still be shown though which we can lookup on Identity. Regards, Ben After phase 2? Cheers, Albert > > The vast majority of projects should now be migrated to Phabricator, > with only historical reviews needing to be cleaned up. > > Note that due to how Reviewboard stores diffs and reproduces them for > use, some reviews may have decayed and may no longer be readable. This > is due to short-hashes which are used by Git/Reviewboard in diffs now > having collisions with other commits which previously did not exist. > Unfortunately there is nothing we can do about this. > > Any comments on the above? > > Regards, > Ben
Re: Retirement of Reviewboard - Transition to Phabricator
On Mon, Aug 28, 2017 at 8:20 PM, René J.V. Bertin wrote: > On Friday August 25 2017 07:33:43 Ben Cooksley wrote: > > Hi, Hi Rene, > >>> Note that due to how Reviewboard stores diffs and reproduces them for >>> use, some reviews may have decayed and may no longer be readable. This >>> is due to short-hashes which are used by Git/Reviewboard in diffs now >>> having collisions with other commits which previously did not exist. >>> Unfortunately there is nothing we can do about this. > > This is probably a "wild thought", but would it be possible somehow to limit > the issue by not letting the ReviewBoard software compare to each repo's HEAD > but against whatever commit is current now (or when you retire the thing)? Reviewboard to my knowledge compares against the commit sha's mentioned in the diff. > > And FWIW, you're aware of git-diff's --full-index option? ;) This is something the contributor could have done when uploading yes, but isn't something we can do anything about now. > > R. Regards, Ben
Re: Urgent: Is the domain koffice.net still needed?
On Tue, Mar 20, 2018 at 8:37 AM, Thomas Pfeiffer wrote: > Dear Calligra team, Hi all, > we just got notified that the domain koffice.net is about to expire and has > to be renewed, and sysadmin asked the board whether the domain is still used. > Since KOffice has not been around for years now, we wonder if you still need > the old domain as a redirect to calligra.org, or if we can drop it. > The domain is set to expire by Friday (March 23rd). Please note that koffice.org is also coming up for renewal one day after koffice.net, so comments on that would also be appreciated. > > If we do not get a reply from someone by *Thursday, March 22nd, 23:59:59 CET* > saying that the domain is still needed, we are going to drop the domain > koffice.net. > > Thank you, > Thomas > > Regards, Ben
Re: Urgent: Is the domain koffice.net still needed?
On 21/03/2018 3:13 AM, "Jaroslaw Staniek" wrote: On 20 March 2018 at 13:46, Dag wrote: > Afaik we do not need koffice.net and koffice.org. > koffice.org just points to calligra.org, and koffice.net does not have any > content. We have a number of links to articles of koffice.org what for my understanding represents is huge part of what KDE was and thus, what it is. Another example is the Kontact suite. Unfortunately just about all those links will be long dead and broken as the content of koffice.org was lost at some point. Therefore all those links will get you now is a 404 page. Only the Wayback Machine will have anything useful now. We had some discussion this month about preserving these links. Regardless technicalities and of availability volunteers to do that, this will not be possible if we loose the domain to hijackers so I would propose to keep it. And hope this will be not a disaster for the budget. :) Given that the last KOffice release was 7 years ago (per Wikipedia) I'm not sure how much value or interest there is in keeping it alive. Regarding koffice.net, it's not important at all. Regards, Ben > > --- > Cheers, > > Dag > > > > Ben Cooksley skrev den 2018-03-20 07:25: >> >> On Tue, Mar 20, 2018 at 8:37 AM, Thomas Pfeiffer >> wrote: >>> >>> Dear Calligra team, >> >> >> Hi all, >> >>> we just got notified that the domain koffice.net is about to expire and >>> has to be renewed, and sysadmin asked the board whether the domain is still >>> used. >>> Since KOffice has not been around for years now, we wonder if you still >>> need the old domain as a redirect to calligra.org, or if we can drop it. >>> The domain is set to expire by Friday (March 23rd). >> >> >> Please note that koffice.org is also coming up for renewal one day >> after koffice.net, so comments on that would also be appreciated. >> >>> >>> If we do not get a reply from someone by *Thursday, March 22nd, 23:59:59 >>> CET* saying that the domain is still needed, we are going to drop the domain >>> koffice.net. >>> >>> Thank you, >>> Thomas >>> >>> >> >> Regards, >> Ben -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org KEXI: : A visual database apps builder - http://calligra.org/kexi http://twitter.com/kexi_project https://facebook.com/kexi.project Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 - Build # 1 - Failure!
On Wed, Jul 25, 2018 at 9:03 PM, Jaroslaw Staniek wrote: > Hi Calligra Devs, > Thanks to Ben, we're getting a Jenkins view for Calligra builds: > https://build.kde.org/view/Calligra/. > I am forwarding info on one defect so you have opportunity to fix this > dependency to make Calligra auto-build on Windows! > One way I would imagine is to make Prison optional dependency. Another to > make it temporarily off on Windows or optional on Windows. > > @Ben > I understand this issue is not affecting kexi* builds for Windows? > Because the Dependency Build has failed to complete, none of the builds can be enabled until it can complete successfully. Note that it isn't Calligra depending on Prison, it's Calligra depending on Akonadi's contacts component, which in turn hard depends on Prison, that is the problem. Regards, Ben > > -- Forwarded message -- > From: Ben Cooksley > Date: 25 July 2018 at 10:53 > Subject: Fwd: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 > - Build # 1 - Failure! > To: Jaroslaw Staniek > > > Hey Jaroslaw, > > I'm afraid you'll need to resolve this before we can continue with > Calligra on Windows CI builds. > > If akonadi-contacts is an optional dependency of Calligra we can exclude > it, otherwise you'll have to arrange for > > > Prison's dependencies to be buildable on Windows using Craft.. > > Cheers, > Ben > > -- Forwarded message -- > From: CI System > Date: Wed, Jul 25, 2018 at 12:20 AM > Subject: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 - > Build # 1 - Failure! > To: bcooks...@kde.org > > > *BUILD FAILURE* > Build URL https://build.kde.org/job/Dependency%20Build%20Calligra%20kf > 5-qt5%20WindowsMSVCQt5.10/1/ > Project: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 > Date of build: Tue, 24 Jul 2018 09:12:57 + > Build duration: 3 hr 7 min and counting > * CONSOLE OUTPUT * > [...truncated 38.40 MB...] > PROCESSOR_LEVEL = '6' > PROCESSOR_REVISION = '3d02' > PROGRAMDATA = 'C:\ProgramData' > PROGRAMFILES = 'C:\Program Files' > PROGRAMFILES(X86) = 'C:\Program Files (x86)' > PROGRAMW6432 = 'C:\Program Files' > PROMPT = '$P$G' > PSMODULEPATH = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' > PUBLIC = 'C:\Users\Public' > RUN_CHANGES_DISPLAY_URL = 'https://build.kde.org/job/Dep > endency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/d > isplay/redirect?page=changes' > RUN_DISPLAY_URL = 'https://build.kde.org/job/Dep > endency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/d > isplay/redirect' > STAGE_NAME = 'Build Product Dependencies' > SYSTEMDRIVE = 'C:' > SYSTEMROOT = 'C:\WINDOWS' > TEMP = 'C:\Users\Jenkins\AppData\Local\Temp' > TMP = 'C:\Users\Jenkins\AppData\Local\Temp' > UCRTVERSION = '10.0.17134.0' > UNIVERSALCRTSDKDIR = 'C:\Program Files (x86)\Windows Kits\10\' > USERDOMAIN = 'DESKTOP-66R8QOQ' > USERNAME = 'Jenkins' > USERPROFILE = 'C:\Users\Jenkins' > VCIDEINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\Common7\IDE\VC\' > VCINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\' > VCTOOLSINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\' > VCTOOLSREDISTDIR = 'C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Redist\MSVC\14.14.26405\' > VCTOOLSVERSION = '14.14.26428' > VISUALSTUDIOVERSION = '15.0' > VS140COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio > 14.0\Common7\Tools\' > VS150COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\Common7\Tools\' > VSCMD_ARG_APP_PLAT = 'Desktop' > VSCMD_ARG_HOST_ARCH = 'x64' > VSCMD_ARG_TGT_ARCH = 'x64' > VSCMD_VER = '15.7.3' > VSINSTALLDIR = 'C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\' > WINDIR = 'C:\WINDOWS' > WINDOWSLIBPATH = 'C:\Program Files (x86)\Windows > Kits\10\UnionMetadata\10.0.17134.0;C:\Program Files (x86)\Windows > Kits\10\References\10.0.17134.0' > WINDOWSSDKBINPATH = 'C:\Program Files (x86)\Windows Kits\10\bin\' > WINDOWSSDKDIR = 'C:\Program Files (x86)\Windows Kits\10\' > WINDOWSSDKLIBVERSION = '10.0.17134.0\' > WINDOWSSDKVERBINPATH = 'C:\Program Files (x86)\Windows > Kits\10\bin\10.0.17134
[sysadmin/ci-tooling] local-metadata: Remove akonadi-contacts as a dependency of Calligra on Windows due to it's hard dependency on Prison (whose dependencies are unavailable on Windows at this time)
Git commit b4734fb0228a8eb937dec4b5fd7aa6f7a1b0c19b by Ben Cooksley. Committed on 27/07/2018 at 09:27. Pushed by bcooksley into branch 'master'. Remove akonadi-contacts as a dependency of Calligra on Windows due to it's hard dependency on Prison (whose dependencies are unavailable on Windows at this time) CCMAIL: calligra-devel@kde.org M +2-0local-metadata/dependency-win32 https://commits.kde.org/sysadmin/ci-tooling/b4734fb0228a8eb937dec4b5fd7aa6f7a1b0c19b diff --git a/local-metadata/dependency-win32 b/local-metadata/dependency-win32 index 7394463..ebdd587 100644 --- a/local-metadata/dependency-win32 +++ b/local-metadata/dependency-win32 @@ -1,3 +1,5 @@ frameworks/kdelibs4support: kdesupport/kdewin kde/kdegraphics/okular: -frameworks/purpose + +calligra/calligra: -kde/pim/akonadi-contacts
Re: Fwd: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 - Build # 1 - Failure!
On Fri, Jul 27, 2018 at 6:34 AM, Dag wrote: > From cmake: > * KF5AkonadiContact , Library for Accessing Contacts stored in Akonadi , > <https://www.kde.org/> >Optionally used by Plan > * KF5Akonadi , Library for general Access to Akonadi , > <https://www.kde.org/> >Optionally used by semantic items Event and Contact > > Plan's use og KF5AkonadiContact is atm not working but needs a > reimplementation anyways to be useful, > so I have no problem with removing it for Windows. > > The semantic items stuff is also not working atm, it has not yet been ported > properly I think. > So at least for the near future, there should be no problem with making it > optional for Windows. Thanks Dag, I've now made the CI system ignore Akonadi Contacts for Calligra on Windows. I'll start a fresh Dependency Build run for Calligra shortly. > > > --- > Cheers, > > Dag Cheers, Ben > > > > Jaroslaw Staniek skrev den 2018-07-25 11:03: >> >> Hi Calligra Devs, >> Thanks to Ben, we're getting a Jenkins view for Calligra builds: >> https://build.kde.org/view/Calligra/. >> I am forwarding info on one defect so you have opportunity to fix this >> dependency to make Calligra auto-build on Windows! >> One way I would imagine is to make Prison optional dependency. Another >> to make it temporarily off on Windows or optional on Windows. >> >> @Ben >> I understand this issue is not affecting kexi* builds for Windows? >> >> -- Forwarded message -- >> From: BEN COOKSLEY >> Date: 25 July 2018 at 10:53 >> Subject: Fwd: KDE CI: Dependency Build Calligra kf5-qt5 >> WindowsMSVCQt5.10 - Build # 1 - Failure! >> To: Jaroslaw Staniek >> >> Hey Jaroslaw, >> >> I'm afraid you'll need to resolve this before we can continue with >> Calligra on Windows CI builds. >> >> If akonadi-contacts is an optional dependency of Calligra we can >> exclude it, otherwise you'll have to arrange for >> >> Prison's dependencies to be buildable on Windows using Craft.. >> >> Cheers, >> Ben >> >> -- Forwarded message -- >> From: CI SYSTEM >> Date: Wed, Jul 25, 2018 at 12:20 AM >> Subject: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 - >> Build # 1 - Failure! >> To: bcooks...@kde.org >> >> BUILD FAILURE >> >> Build URL >> >> https://build.kde.org/job/Dependency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/ >> [1] >> >> Project: >> Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 >> >> Date of build: >> Tue, 24 Jul 2018 09:12:57 + >> >> Build duration: >> 3 hr 7 min and counting >> >> CONSOLE OUTPUT >> >> [...truncated 38.40 MB...] >> >> PROCESSOR_LEVEL = '6' >> >> PROCESSOR_REVISION = '3d02' >> >> PROGRAMDATA = 'C:\ProgramData' >> >> PROGRAMFILES = 'C:\Program Files' >> >> PROGRAMFILES(X86) = 'C:\Program Files (x86)' >> >> PROGRAMW6432 = 'C:\Program Files' >> >> PROMPT = '$P$G' >> >> PSMODULEPATH = >> 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' >> >> PUBLIC = 'C:\Users\Public' >> >> RUN_CHANGES_DISPLAY_URL = >> >> 'https://build.kde.org/job/Dependency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/display/redirect?page=changes >> [2]' >> >> RUN_DISPLAY_URL = >> >> 'https://build.kde.org/job/Dependency%20Build%20Calligra%20kf5-qt5%20WindowsMSVCQt5.10/1/display/redirect >> [3]' >> >> >> STAGE_NAME = 'Build Product Dependencies' >> >> SYSTEMDRIVE = 'C:' >> >> SYSTEMROOT = 'C:\WINDOWS' >> >> TEMP = 'C:\Users\Jenkins\AppData\Local\Temp' >> >> TMP = 'C:\Users\Jenkins\AppData\Local\Temp' >> >> UCRTVERSION = '10.0.17134.0' >> >> UNIVERSALCRTSDKDIR = 'C:\Program Files (x86)\Windows >> Kits\10\' >> >> USERDOM
D16721: Use Krita toolbar in Karbon
bcooksley added a comment. Force pushes are generally reserved for pretty serious issues, couldn't the whitespace be corrected with a follow up commit to remove it? REPOSITORY R8 Calligra REVISION DETAIL https://phabricator.kde.org/D16721 To: ognarb, #calligra:_3.0, anthonyfieroni Cc: bcooksley, anthonyfieroni, Calligra-Devel-list, dcaliste, cochise, vandenoever
D16721: Use Krita toolbar in Karbon
bcooksley added a comment. Anyone who has already pulled in the latest changes will need to forcibly reset their local working tree after the force push is completed. Should they have staged work, this would need to be rebased, which can be a non-trivial process and one many developers will not be familiar with. For those inexperienced with Git, forcibly resetting their local working copy is often not possible and the only way for them to get back to a usable state is for them to completely erase and re-clone the repository. In addition, should they have staged changes, the history of those changes could be lost (unless extreme care were taken) and in some cases people have accidentally erased work they've already completed. For these reasons Force Pushes are generally reserved for situations where no other option is available to correct the issue. REPOSITORY R8 Calligra REVISION DETAIL https://phabricator.kde.org/D16721 To: ognarb, #calligra:_3.0, anthonyfieroni Cc: bcooksley, anthonyfieroni, Calligra-Devel-list, dcaliste, cochise, vandenoever
Transitioning CI builds of all non-Frameworks from Qt 5.9
Hi all, I've been informed by the PIM developers that they would like to bump the dependency of the Qt version they use, from Qt 5.9 which it's on currently, to Qt 5.10. As a consequence, due to many KDE projects using PIM libraries, their dependency on Qt will also be effectively bumped. To minimize the maintenance cost of this bump for the CI system, I would like to bump everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end up chasing down build failures for a long time) As most distributions have moved on from 5.10, and use Qt 5.11 now (and will in many cases soon move to Qt 5.12), i'd like to suggest that instead of going to Qt 5.10, we move straight to 5.11. Because Frameworks has a two versions prior support policy, it'll remain on 5.9 for now until it's ready to move up to 5.10 (assuming 5.12 is a usable Qt version) If nobody has any objections, i'll proceed with this change in around 3 days time. Cheers, Ben
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On Mon, Dec 3, 2018 at 10:31 PM René J.V. Bertin wrote:
>
> Hi,
>
> Can't you just configure the CI to use Qt 5.10? I think it's not good to
> hardcode an "overzealous" (for lack of a better word) Qt version in projects
> that don't require them AND I think that one should support the current LTS
> release in as many projects as possible as a general rule of principle.
Not really, because it won't be long before 5.10 is no longer any of
the current mainstream distributions.
>
> There's a reason why those LTS releases exist and that should probably be
> taken into consideration ESPECIALLY for the KF5 Frameworks (remember why
> kdelibs4 was split up)!
As mentioned in my mail, this applies to everything but Frameworks.
It doesn't affect Frameworks - which will continue on Qt 5.9 at this stage.
>
> People working only on Linux may not realise it but even Qt 5.9 already
> dropped support for Mac OS versions that are still widely used.
>
> IMHO, projects that use PIM libraries can decide for themselves how they want
> to deal with a Qt minimum version bump in those dependencies, while
> distribution maintainers *could* decide to keep those (and only those)
> dependencies on an earlier version in order to keep supporting whatever
> oldest Qt requirement they have (5.9 for my MacPorts packaging). Also, don't
> of those projects have only optional dependencies on PIM libraries?
For some it's mandatory.
>
> I tend to see a CI as something that tests software on one or a handful of
> the most common configurations. Anyone not using such a configuration is
> either on their own or acting as a kind of additional CI.
>
> Bumping the minimum Qt version across the line would decrease the burden on
> the CI, but probably increase the burden on distributions, or force them to
> stop following upgrades earlier than justified.
>
> Also:
> > (otherwise we'll end up chasing down build failures for a long time)
>
> How so? If you want to install project B that requires Qt 5.9+ but also uses
> PIM library A which requires Qt 5.1x you're going to need to install
> something newer than Qt 5.9 . What kind of build failures we cannot already
> get ("B requires PIM library A which is not installed") are you expecting?
The CI system has no way of knowing what a project says it requires.
It relies on it's own configuration files to dictate what jobs are
generated, and those jobs in turn determine what platform they're run
on.
What i'm referring to here is the manual process of having to go and
exclude various projects which do use PIM libraries (the CI system
doesn't have a concept of optional, it's either needed or not present
at all). The only way to do this will be by hunting through the
dependency graph, which is easier said than done (because Application
A uses library B which uses library C which in turn uses PIM library
D)
Individual project failures might not seem too bad, apart from the
fact it's me (or one of the handful of people familiar with the CI
system configuration) who will have to update the configuration for
many projects (which will result in either lots of Sysadmin tickets,
or a ton of various people spending time hunting these issues down).
Note that in order for the CI system to operate properly the
"Dependency Build" jobs need to be able to run successfully (otherwise
you'll have missing dependencies when you go to run a build). In most
cases it won't be jobs themselves that fail, it'll be the Dependency
Build jobs - and because these jobs start from scratch (ECM, then up
through Frameworks and so on until every project's dependencies have
been built) it's extremely expensive to keep running these jobs as
they occupy builders for quite a bit of time.
> There could be errors from *other* projects not depending on PIM libraries,
> but if they intend to support an "older" Qt version that implies rather
> explicitly that they also intend to address build failures, no?
>
We see those on a semi-regular basis - as those who have seen QtTest
casting issues will be well aware.
>
> R.
Cheers,
Ben
Re: Transitioning CI builds of all non-Frameworks from Qt 5.9
On Tue, Dec 4, 2018 at 9:45 AM Elvis Angelaccio wrote: > > > > On 03/12/18 09:46, Ben Cooksley wrote: > > Hi all, > > Hi Ben Hi Elvis, > > > > > I've been informed by the PIM developers that they would like to bump > > the dependency of the Qt version they use, from Qt 5.9 which it's on > > currently, to Qt 5.10. > > > > As a consequence, due to many KDE projects using PIM libraries, their > > dependency on Qt will also be effectively bumped. To minimize the > > maintenance cost of this bump for the CI system, I would like to bump > > everyone up from Qt 5.9 to a newer version of Qt (otherwise we'll end > > up chasing down build failures for a long time) > > It's not clear if you are suggesting to bump the minimum required Qt > version in each CMakeLists.txt file, or if you are just going to bump > the Qt version used by the CI server. > > Could you please clarify? Thanks! I'll only be bumping the version used by the CI system, the applications themselves will be left unchanged. > > > > > As most distributions have moved on from 5.10, and use Qt 5.11 now > > (and will in many cases soon move to Qt 5.12), i'd like to suggest > > that instead of going to Qt 5.10, we move straight to 5.11. > > > > Because Frameworks has a two versions prior support policy, it'll > > remain on 5.9 for now until it's ready to move up to 5.10 (assuming > > 5.12 is a usable Qt version) > > > > If nobody has any objections, i'll proceed with this change in around > > 3 days time. > > > > Cheers, > > Ben > > > > Cheers, > Elvis Cheers, Ben
T10760: Calligra website unwanted blog content
bcooksley closed this task as "Resolved". bcooksley claimed this task. bcooksley added a comment. @ongunkanat Thank you for reporting this issue to us. I have now corrected the issue and only legitimate content should now be displayed. @staniek @danders The Lifestream code was integrated directly as part of the theme itself, and coded in PHP (likely because Wordpress doesn't support this sort of functionality natively) I have now replaced the URLs with their modern equivalents, on blogs.kde.org. root@edulis /srv/www/wordpress/calligra.org/wp-content/themes/calligra # grep -ir kdedevelopers * lifestream.php: 'http://www.kdedevelopers.org/blog/1236/feed', // Casper Boemann lifestream.php: 'http://www.kdedevelopers.org/blog/268/feed', // Jos van den Oever lifestream.php: 'http://www.kdedevelopers.org/blog/7783/feed', // Marc Pegon lifestream.php: 'http://www.kdedevelopers.org/blog/2892/feed', // Marijn Kruisselbrink root@edulis /srv/www/wordpress/calligra.org/wp-content/themes/calligra # vim lifestream.php root@edulis /srv/www/wordpress/calligra.org/wp-content/themes/calligra # grep -ir kdedevelopers * root@edulis /srv/www/wordpress/calligra.org/wp-content/themes/calligra # TASK DETAIL https://phabricator.kde.org/T10760 To: bcooksley Cc: bcooksley, staniek, danders, #sysadmin, Calligra-Devel-list, #calligra:_3.0, ongunkanat, sysadmin
Issues with Jenkins Builds
Hi all, Recently we were affected by a regression within Jenkins, the effect of which meant that in some circumstances builds would not be triggered when new commits were introduced. In addition, the views showing the list of all builds would also not show the last successfully completed build in some circumstances. This fault has now been worked around on build.kde.org, and rebuilds have been initiated of a number of jobs which have been identified as either affected or potentially affected, which unfortunately will take the better part of the next day or so for the system to process. For all those projects not being rebuilt, maintainers are asked to please check their builds to ensure that the latest build reflects the current state of their repository. Particular attention should be paid to stable builds, which are the most likely to be affected by the above issues. Should your project(s) builds be affected by this issue (with the latest build being an old one) then the issue will be corrected by performing a rebuild manually, after which it should behave properly. Please respond to this email with the names of the affected projects and we'll arrange for this if you don't have access to do this yourself. Apologies for the inconvenience caused. Regards, Ben Cooksley KDE Sysadmin
KDiagram - Persistent FTBFS for stable branch on Windows
Hi KDiagram Developers, The stable branch of KDiagram has been persistently failing to build from source now on Windows for a period greater than 5 days. It would be appreciated if you could please remedy this situation without delay, as your failure prevents the CI system from operating services correctly for the following projects: - KStars - Konversation - Skrooge - Okteta - KDiff3 - Alkimia - KMyMoney - KRename Regards, Ben
Re: KDiagram - Persistent FTBFS for stable branch on Windows
On Mon, Oct 12, 2020 at 10:24 PM Milian Wolff wrote: > On Montag, 12. Oktober 2020 11:11:22 CEST Ben Cooksley wrote: > > Hi KDiagram Developers, > > > > The stable branch of KDiagram has been persistently failing to build from > > source now on Windows for a period greater than 5 days. > > Hey Ben, > Hi Milian, > > can you link me to such a CI failure? Then I could try to blind-fix it, as > I > don't have a KDE-on-windows setup here. But maybe it's simple enough to > fix > even without that. > I suspect the fix just needs cherry picking - hopefully it isn't too complicated to fix. The failure log is at https://build.kde.org/job/Calligra/job/kdiagram/job/stable-kf5-qt5%20WindowsMSVCQt5.15/4/consoleText More recent builds can be found at https://build.kde.org/job/Calligra/job/kdiagram/job/stable-kf5-qt5%20WindowsMSVCQt5.15/ > > Cheers > Cheers, Ben > > > It would be appreciated if you could please remedy this situation without > > delay, as your failure prevents the CI system from operating services > > correctly for the following projects: > > - KStars > > - Konversation > > - Skrooge > > - Okteta > > - KDiff3 > > - Alkimia > > - KMyMoney > > - KRename > > -- > Milian Wolff > m...@milianw.de > http://milianw.de
ACTION REQUIRED - Gitlab and Subversion server migration
Good morning KDE Developers, As many of you will be aware, today Gitlab and our Subversion repository were both migrated to a new home - on a more modern and more powerful server, which should better support future work. As a consequence the host key of the server has now changed, which means you will need to take steps on your system otherwise you won't be allowed to connect to the new server. Please ensure you run the following two commands to clear out any existing host keys: - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts Following these commands the next time you try to connect you will be prompted to confirm the new host key and trust it for use. For those who would like to confirm that host key, it is as follows: 256 SHA256:zHdK2R/S6s5Oj71N0s8LHWCXXsUt+DCztd+GjzW9KlU root@lerwini (ED25519) 256 SHA256:ZNBg4AkRxbt/N6xzpt7GbmmS78A3WFy5lz0l/cPHbcE root@lerwini (ECDSA) 3072 SHA256:KxAoV6VsbKvAocFZCJlxtmPDScmUCRNiUiOCSXNSC/k root@lerwini (RSA) Please let us know, via either sysad...@kde.org or kde-de...@kde.org if you encounter any issues with the new system. Many thanks, Ben Cooksley KDE Sysadmin
Re: ACTION REQUIRED - Gitlab and Subversion server migration
On Tue, Jul 25, 2023 at 1:35 AM Vít Pelčák wrote: > > ne 23. 7. 2023 v 12:01 odesílatel Ben Cooksley napsal: > >> Good morning KDE Developers, >> >> As many of you will be aware, today Gitlab and our Subversion repository >> were both migrated to a new home - on a more modern and more powerful >> server, which should better support future work. >> >> As a consequence the host key of the server has now changed, which means >> you will need to take steps on your system otherwise you won't be allowed >> to connect to the new server. >> >> Please ensure you run the following two commands to clear out any >> existing host keys: >> - ssh-keygen -R invent.kde.org -f ~/.ssh/known_hosts >> - ssh-keygen -R svn.kde.org ~/.ssh/known_hosts >> > > I suppose you meant > ssh-keygen -R svn.kde.org -f ~/.ssh/known_hosts > That is correct. > > right? > > Cheers, Ben
Calligra Repository Viewing
Hi, Just to let you know, but a temporary fix has been found to the KDE Projects performance issues, so Calligra repository browsing has now been re-enabled at KDE Projects. https://projects.kde.org/projects/calligra/repository Regards, Ben KDE Sysadmin ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra Repository Viewing
On Tue, Jan 25, 2011 at 11:41 PM, Cyrille Berger Skott wrote: > Hi, > > Thanks for the head up. > > On Tuesday 25 January 2011, Ben Cooksley wrote: >> Just to let you know, but a temporary fix has been found to the KDE >> Projects performance issues > > How temporary ? Or do you just mean that it is a horrible hack and a proper > fix just need to be found inside redmine ? Temporary in this case means that we have had to reduce the functionality of the repository browser in order to provide fast performance. It isn't a hack as such fortunately. The real cause of the slow performance is actually in git itself (as git log has to be invoked for each file/folder in the directory being viewed), it is probable that some form of SQL based cache will need to be established to allow that information to return. Regards, Ben > > -- > Cyrille Berger Skott > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Website downtime
Hi all, Just a quick notice that sysadmin has scheduled downtime for the following below sites from UTC (12am) on Friday. It is unknown how long downtime will last at this time. This is necessary to allow for sites to be migrated to a new server. All of the sites will be completely inaccessible, and will return one by one as they are migrated and verified as fully operational on the new system. Apologies for any inconvenience. As DNS changes are required to perform the server move, sites may appear to be down long after they have been restored. The affected sites (in no particular order) are: - dot.kde.org - techbase.kde.org - userbase.kde.org - community.kde.org - forum.kde.org - akademy.kde.org - amarok.kde.org - kdevelop.org - krita.org - calligra.org - digikam.org These sites will also be affected by the downtime: - akademy2010.kde.org - akademy2012.kde.org - akademy2013.kde.org - behindkde.org - blogs.kde.org - br.kde.org - desktopsummit.org - dev.krita.org - discover.kde.org - eduini.kde.org - ir.kde.org - k3b.kde.org - kde.in - kde.nl - simon.kde.org - speech.kde.org - staging.vdesign.kde.org - sysadmin.kde.org - tasks.kde.org - uwg.kde.org - wiki.akademy.kde.org - wiki.br.kde.org - wiki.desktopsummit.org Thanks, Ben Cooksley KDE Sysadmin ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Website downtime
Hi all, Just a quick note that the migrations for all sites have now been completed. As the server setup has changed drastically please let sysadmin know if you uncover anything which is broken or no longer functioning correctly. Please note that we have also rolled out mandatory SSL for all of those sites as well, so applications which interact with them and which cannot handle SNI or redirects will now no longer function. In addition, as we require a decent set of SSL ciphers to be supported, some older SSL stacks will also be incompatible. Please contact sysadmin if this affects your application or end users negatively. It would be appreciated if those using Drupal 6 instances could contact sysadmin so we can make plans to migrate those sites to Drupal 7. The newer version of PHP in use on the new system causes Drupal 6 quite a few issues. Thanks, Ben Cooksley KDE Sysadmin ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Why to redirect to https for calligra.org?
On 28 July 2014 09:08, Jaroslaw Staniek wrote: > Hi, Hi Jaroslaw, > Probably picky question to Cyrille but CC'd Ben to be safe. > Asking because I'd like to see browsers to show calligra.org as a trusted > site. > > It's almost perfect but I see redirection to https://calligra.org from > http://www.calligra.org in my browsers. > So far so good but Firefox nicely explains "This website does not > supply identity information". > Is there any easy fix fort that? For me using http as for many other > KDE sites (unless logged-in) could be a fix. The redirect is part of sysadmin's rollout of mandatory SSL and site canonicalisation to all KDE websites. Even though login is not used for the majority of the Calligra (or many KDE websites) it is now seen as general good practice to provide browsing over HTTPS. Very few websites (not even Google) use the "Extended Validation" certificates required to "provide identity information". They're also extremely costly. I don't think we need to worry about this - it won't affect the display of the padlock/trusted site part. > > I see two problems explained here: > https://support.mozilla.org/en-US/questions/983078#answer-521848 > > - Not supplying identity information - > http://wstaw.org/m/2014/07/27/plasma-desktopCY2313.png > - Gray exclamation-triangle - > http://wstaw.org/m/2014/07/27/plasma-desktopPd2313.png > Loading mixed (insecure) display content can be fixed (3 warnings) but > wouldn't change back to http be a cleaner fix? I'll fix the elements in the theme which are causing these warnings. Switching to http:// based browsing would only be a workaround for the issue. > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Why to redirect to https for calligra.org?
On 28 July 2014 11:41, Ben Cooksley wrote: > On 28 July 2014 09:08, Jaroslaw Staniek wrote: >> Hi, > > Hi Jaroslaw, > >> Probably picky question to Cyrille but CC'd Ben to be safe. >> Asking because I'd like to see browsers to show calligra.org as a trusted >> site. >> >> It's almost perfect but I see redirection to https://calligra.org from >> http://www.calligra.org in my browsers. >> So far so good but Firefox nicely explains "This website does not >> supply identity information". >> Is there any easy fix fort that? For me using http as for many other >> KDE sites (unless logged-in) could be a fix. > > The redirect is part of sysadmin's rollout of mandatory SSL and site > canonicalisation to all KDE websites. > Even though login is not used for the majority of the Calligra (or > many KDE websites) it is now seen as general good practice to provide > browsing over HTTPS. > > Very few websites (not even Google) use the "Extended Validation" > certificates required to "provide identity information". They're also > extremely costly. > I don't think we need to worry about this - it won't affect the > display of the padlock/trusted site part. > >> >> I see two problems explained here: >> https://support.mozilla.org/en-US/questions/983078#answer-521848 >> >> - Not supplying identity information - >> http://wstaw.org/m/2014/07/27/plasma-desktopCY2313.png >> - Gray exclamation-triangle - >> http://wstaw.org/m/2014/07/27/plasma-desktopPd2313.png >> Loading mixed (insecure) display content can be fixed (3 warnings) but >> wouldn't change back to http be a cleaner fix? > > I'll fix the elements in the theme which are causing these warnings. > Switching to http:// based browsing would only be a workaround for the issue. The changes have now been applied. > >> >> -- >> regards / pozdrawiam, Jaroslaw Staniek >> Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >> Qt for Tizen | http://qt-project.org/wiki/Tizen >> Qt Certified Specialist | http://www.linkedin.com/in/jstaniek > > Thanks, > Ben Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 09:54, Jaroslaw Staniek wrote: > On 28 July 2014 20:36, Cyrille Berger wrote: > >> >> Sounds nice, do you know if it is possible to make the lists (or some of >> them) >> public ? Hi Jaroslaw, Cyrille, > > Good question, I've not found any board's settings. > > @Martin, Ben? I'm afraid Kanboard does not support making boards directly public at the moment - however it can produce a "read only" URL which anyone can use to access it. Anyone with an Identity account can access it however. This is https://todo.kde.org/?controller=board&action=readonly&token=95edd35971d17b59a084348500139ab7dd53798e5c58ec9e03483c5dfc2c for the Calligra board. > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 10:41, Jaroslaw Staniek wrote: > On 29 July 2014 00:12, Ben Cooksley wrote: >> On 29 July 2014 09:54, Jaroslaw Staniek wrote: >>> On 28 July 2014 20:36, Cyrille Berger wrote: >>> >>>> >>>> Sounds nice, do you know if it is possible to make the lists (or some of >>>> them) >>>> public ? >> >> Hi Jaroslaw, Cyrille, >> >>> >>> Good question, I've not found any board's settings. >>> >>> @Martin, Ben? >> >> I'm afraid Kanboard does not support making boards directly public at >> the moment - however it can produce a "read only" URL which anyone can >> use to access it. Anyone with an Identity account can access it >> however. >> This is >> https://todo.kde.org/?controller=board&action=readonly&token=95edd35971d17b59a084348500139ab7dd53798e5c58ec9e03483c5dfc2c >> for the Calligra board. >> > > Thanks Ben. > Another question is about support for working groups (not per boards). > Can this be set up by separating the database for example? For now > there're kind-of usability challenges already: This would require a separate instance of Kanboard, and would create two places for people to work in. I'd rather not have that... > > * we need to pick users from a long list when filtering or assigning tasks > * we need to pick board from a list that's getting longer (see, today > 4 new created for Calligra and there would be many more) > > Looks like there may be many more wishes from hungry users :) Please note that Kanboard is OSS software, which is hosted on Github. Someone has already been in contact with the maintainer for it, and from what I understand they may be interested in adding certain functionality. At this time, the list of boards is not too long (and is searchable anyway) so I don't think that will pose a problem. In regards to assigning people, that indeed does appear to be functionality which could be improved - however I think search rather than grouping would be more helpful here. Giving each project their own instance is unsustainable i'm afraid - and wouldn't cure the list of users problem anyway, as it requires login to view unless you have one of the readonly URLs - and once someone has logged in their account now exists within Kanboard. > >>> >>> >>> -- >>> regards / pozdrawiam, Jaroslaw Staniek >>> Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >>> Qt for Tizen | http://qt-project.org/wiki/Tizen >>> Qt Certified Specialist | http://www.linkedin.com/in/jstaniek >> >> Thanks, >> Ben > > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 11:08, Jaroslaw Staniek wrote: > On 29 July 2014 00:52, Ben Cooksley wrote: > [..] >> Giving each project their own instance is unsustainable i'm afraid - >> and wouldn't cure the list of users problem anyway, as it requires >> login to view unless you have one of the readonly URLs - and once >> someone has logged in their account now exists within Kanboard. > > Ah, and a question before I fill todos in my project: anyone tested > iceScrum (AGPL) that seems more complete _now_? IceScrum was previously evaluated by Plasma folks and found to be unworkable. > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 11:18, Jaroslaw Staniek wrote: > BTW, > Any idea how to add Categories of Tasks? The list is empty everywhere I think. An administrator can create categories for you. > > While Iunderstand rules of simplicity when for 3 users or so, I am > also afraid one thing. There are dozens of users in our instance and > no traces of access management (except for creating new boards). > Everyone can (even by accident) edit/drag/drop/delete any tasks of any > board... That is correct. It does actually support restricting access to boards - but then anyone who hasn't been added to the board can't even view it. In this case, one simply needs to trust that people will do the right thing. Regards, Ben > > > On 29 July 2014 00:52, Ben Cooksley wrote: >> On 29 July 2014 10:41, Jaroslaw Staniek wrote: >>> On 29 July 2014 00:12, Ben Cooksley wrote: >>>> On 29 July 2014 09:54, Jaroslaw Staniek wrote: >>>>> On 28 July 2014 20:36, Cyrille Berger wrote: >>>>> >>>>>> >>>>>> Sounds nice, do you know if it is possible to make the lists (or some of >>>>>> them) >>>>>> public ? >>>> >>>> Hi Jaroslaw, Cyrille, >>>> >>>>> >>>>> Good question, I've not found any board's settings. >>>>> >>>>> @Martin, Ben? >>>> >>>> I'm afraid Kanboard does not support making boards directly public at >>>> the moment - however it can produce a "read only" URL which anyone can >>>> use to access it. Anyone with an Identity account can access it >>>> however. >>>> This is >>>> https://todo.kde.org/?controller=board&action=readonly&token=95edd35971d17b59a084348500139ab7dd53798e5c58ec9e03483c5dfc2c >>>> for the Calligra board. >>>> >>> >>> Thanks Ben. >>> Another question is about support for working groups (not per boards). >>> Can this be set up by separating the database for example? For now >>> there're kind-of usability challenges already: >> >> This would require a separate instance of Kanboard, and would create >> two places for people to work in. I'd rather not have that... >> >>> >>> * we need to pick users from a long list when filtering or assigning tasks >>> * we need to pick board from a list that's getting longer (see, today >>> 4 new created for Calligra and there would be many more) >>> >>> Looks like there may be many more wishes from hungry users :) >> >> Please note that Kanboard is OSS software, which is hosted on Github. >> Someone has already been in contact with the maintainer for it, and >> from what I understand they may be interested in adding certain >> functionality. >> At this time, the list of boards is not too long (and is searchable >> anyway) so I don't think that will pose a problem. >> >> In regards to assigning people, that indeed does appear to be >> functionality which could be improved - however I think search rather >> than grouping would be more helpful here. >> >> Giving each project their own instance is unsustainable i'm afraid - >> and wouldn't cure the list of users problem anyway, as it requires >> login to view unless you have one of the readonly URLs - and once >> someone has logged in their account now exists within Kanboard. >>> >>>>> >>>>> >>>>> -- >>>>> regards / pozdrawiam, Jaroslaw Staniek >>>>> Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >>>>> Qt for Tizen | http://qt-project.org/wiki/Tizen >>>>> Qt Certified Specialist | http://www.linkedin.com/in/jstaniek >>>> >>>> Thanks, >>>> Ben >>> >>> >>> >>> -- >>> regards / pozdrawiam, Jaroslaw Staniek >>> Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >>> Qt for Tizen | http://qt-project.org/wiki/Tizen >>> Qt Certified Specialist | http://www.linkedin.com/in/jstaniek >> >> Thanks, >> Ben > > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 21:50, Jaroslaw Staniek wrote: > On 29 July 2014 09:14, Ben Cooksley wrote: >> On 29 July 2014 11:18, Jaroslaw Staniek wrote: >>> BTW, >>> Any idea how to add Categories of Tasks? The list is empty everywhere I >>> think. >> >> An administrator can create categories for you. >> >>> >>> While Iunderstand rules of simplicity when for 3 users or so, I am >>> also afraid one thing. There are dozens of users in our instance and >>> no traces of access management (except for creating new boards). >>> Everyone can (even by accident) edit/drag/drop/delete any tasks of any >>> board... >> >> That is correct. It does actually support restricting access to boards >> - but then anyone who hasn't been added to the board can't even view >> it. > > OK, what does the "add user to a board" mean? > > I cannot spot a hint at http://kanboard.net/documentation/manage-users It appears that the functionality i'm referring to isn't documented at the moment. It is called "Edit user access" in the admin interface, and controls which users have access to a project. > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 22:00, Jaroslaw Staniek wrote: > On 29 July 2014 11:54, Ben Cooksley wrote: >> On 29 July 2014 21:50, Jaroslaw Staniek wrote: >>> On 29 July 2014 09:14, Ben Cooksley wrote: >>>> On 29 July 2014 11:18, Jaroslaw Staniek wrote: >>>>> BTW, >>>>> Any idea how to add Categories of Tasks? The list is empty everywhere I >>>>> think. >>>> >>>> An administrator can create categories for you. >>>> >>>>> >>>>> While Iunderstand rules of simplicity when for 3 users or so, I am >>>>> also afraid one thing. There are dozens of users in our instance and >>>>> no traces of access management (except for creating new boards). >>>>> Everyone can (even by accident) edit/drag/drop/delete any tasks of any >>>>> board... >>>> >>>> That is correct. It does actually support restricting access to boards >>>> - but then anyone who hasn't been added to the board can't even view >>>> it. >>> >>> OK, what does the "add user to a board" mean? >>> >>> I cannot spot a hint at http://kanboard.net/documentation/manage-users >> >> It appears that the functionality i'm referring to isn't documented at >> the moment. >> It is called "Edit user access" in the admin interface, and controls >> which users have access to a project. > > Oh so how it's now? Who has access to, say, Calligra project/board by > default and now? The default access is to grant everyone who can login access. If we change this however, the project becomes private and only accessible to those who are added. > > Also, are there backups performed, like daily or so? All KDE servers have daily backups performed. Both the on disk files and databases as well as the system configuration is backed up each night and transferred to a separate system. > > Sorry for asking such details but I am used to tools like wikis, where > works from the day before would never dissapear. > > In such systems we'd benefit from either some form of history (now > it's missing?) or backups. > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Regards, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 23:06, Jaroslaw Staniek wrote: > On 29 July 2014 12:09, Ben Cooksley wrote: >> On 29 July 2014 22:00, Jaroslaw Staniek wrote: >>> On 29 July 2014 11:54, Ben Cooksley wrote: >>>> On 29 July 2014 21:50, Jaroslaw Staniek wrote: >>>>> On 29 July 2014 09:14, Ben Cooksley wrote: >>>>>> On 29 July 2014 11:18, Jaroslaw Staniek wrote: >>>>>>> BTW, >>>>>>> Any idea how to add Categories of Tasks? The list is empty everywhere I >>>>>>> think. >>>>>> >>>>>> An administrator can create categories for you. >>>>>> >>>>>>> >>>>>>> While Iunderstand rules of simplicity when for 3 users or so, I am >>>>>>> also afraid one thing. There are dozens of users in our instance and >>>>>>> no traces of access management (except for creating new boards). >>>>>>> Everyone can (even by accident) edit/drag/drop/delete any tasks of any >>>>>>> board... >>>>>> >>>>>> That is correct. It does actually support restricting access to boards >>>>>> - but then anyone who hasn't been added to the board can't even view >>>>>> it. >>>>> >>>>> OK, what does the "add user to a board" mean? >>>>> >>>>> I cannot spot a hint at http://kanboard.net/documentation/manage-users >>>> >>>> It appears that the functionality i'm referring to isn't documented at >>>> the moment. >>>> It is called "Edit user access" in the admin interface, and controls >>>> which users have access to a project. >>> >>> Oh so how it's now? Who has access to, say, Calligra project/board by >>> default and now? >> >> The default access is to grant everyone who can login access. If we >> change this however, the project becomes private and only accessible >> to those who are added. > > Hmm, there's mention of a readonly kiosk mode > (http://kanboard.net/news) but where is it? > > In the code there's "public function readonly()" function which > doesn't seem to be used so far... My guess is that is the read-only URL - which I provided earlier for the Calligra board > > OTOH, good news: > https://github.com/fguillot/kanboard/issues/183#issuecomment-50014336 > > So it's perhaps a matter of waiting... >> >>> >>> Also, are there backups performed, like daily or so? >> >> All KDE servers have daily backups performed. >> Both the on disk files and databases as well as the system >> configuration is backed up each night and transferred to a separate >> system. >> >>> >>> Sorry for asking such details but I am used to tools like wikis, where >>> works from the day before would never dissapear. >>> >>> In such systems we'd benefit from either some form of history (now >>> it's missing?) or backups. >>> >>> >>> -- >>> regards / pozdrawiam, Jaroslaw Staniek >>> Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >>> Qt for Tizen | http://qt-project.org/wiki/Tizen >>> Qt Certified Specialist | http://www.linkedin.com/in/jstaniek >> >> Regards, >> Ben > > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Regards, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Moving Calligra / Kexi TODOs migrate into todo.kde.org
On 29 July 2014 23:39, Jaroslaw Staniek wrote: > On 29 July 2014 13:09, Ben Cooksley wrote: >> On 29 July 2014 23:06, Jaroslaw Staniek wrote: >>> On 29 July 2014 12:09, Ben Cooksley wrote: >>>> On 29 July 2014 22:00, Jaroslaw Staniek wrote: >>>>> On 29 July 2014 11:54, Ben Cooksley wrote: >>>>>> On 29 July 2014 21:50, Jaroslaw Staniek wrote: >>>>>>> On 29 July 2014 09:14, Ben Cooksley wrote: >>>>>>>> On 29 July 2014 11:18, Jaroslaw Staniek wrote: >>>>>>>>> BTW, >>>>>>>>> Any idea how to add Categories of Tasks? The list is empty everywhere >>>>>>>>> I think. >>>>>>>> >>>>>>>> An administrator can create categories for you. >>>>>>>> >>>>>>>>> >>>>>>>>> While Iunderstand rules of simplicity when for 3 users or so, I am >>>>>>>>> also afraid one thing. There are dozens of users in our instance and >>>>>>>>> no traces of access management (except for creating new boards). >>>>>>>>> Everyone can (even by accident) edit/drag/drop/delete any tasks of any >>>>>>>>> board... >>>>>>>> >>>>>>>> That is correct. It does actually support restricting access to boards >>>>>>>> - but then anyone who hasn't been added to the board can't even view >>>>>>>> it. >>>>>>> >>>>>>> OK, what does the "add user to a board" mean? >>>>>>> >>>>>>> I cannot spot a hint at http://kanboard.net/documentation/manage-users >>>>>> >>>>>> It appears that the functionality i'm referring to isn't documented at >>>>>> the moment. >>>>>> It is called "Edit user access" in the admin interface, and controls >>>>>> which users have access to a project. >>>>> >>>>> Oh so how it's now? Who has access to, say, Calligra project/board by >>>>> default and now? >>>> >>>> The default access is to grant everyone who can login access. If we >>>> change this however, the project becomes private and only accessible >>>> to those who are added. >>> >>> Hmm, there's mention of a readonly kiosk mode >>> (http://kanboard.net/news) but where is it? >>> >>> In the code there's "public function readonly()" function which >>> doesn't seem to be used so far... >> >> My guess is that is the read-only URL - which I provided earlier for >> the Calligra board > > OK, I am going to share it, thanks. How to find URLs for the other 3 boards: > Kexi KF5 Port, Kexi, Predicate? The readonly URLs should be retrievable from https://todo.kde.org/?controller=project - i've no idea if that is admin only though. In any case, they are: Kexi KF5: https://todo.kde.org/?controller=board&action=readonly&token=11341e5f4059520ee1abdef93c530123499f6b73c1725c56c6999e750859 Kexi: https://todo.kde.org/?controller=board&action=readonly&token=69ab4131df22cb39ff839ce8e17edaf975abba9df0808fb08826288fb568 Predicate: https://todo.kde.org/?controller=board&action=readonly&token=d65190bd8776982e7006fb7cf71aee6990eb908f66f3e7150ed9d8ce3b13 > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek Thanks, Ben ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.9 Changelog
On Thu, Feb 26, 2015 at 10:01 PM, Jaroslaw Staniek wrote: > On 26 February 2015 at 08:31, Cyrille Berger wrote: >> On 2015-02-25 15:13, Jaroslaw Staniek wrote: >>> >>> Thanks. I have one question @Cyrille. >>> Why are the previous binaries removed (not just 2.8.0 but also 2.8.6?). >> >> When moving to the next major release, I always only keep the last minor >> release of the previous one. The reason is to keep the mirrors small. > > OK I wouldn't worry about using mirror disk space. Sysadmin moves stuff into the Attic as needed. I do hope you've been moving to the Attic and not rm -rf'ing them... > >>> Now users/packagers have no access to previous versions e.g. and links >>> on previous announcements are now broken. This looks rather >>> unprofessional. >> >> >> What we should probably do is to edit the download link then. And replace it >> with links to the tag. > > Sure, while we're in a computer era, any idea how to make it automatic? Please don't use links to the tag tarballs produced by quickgit.kde.org - that will create undue burden. > > We're putting links like > http://download.kde.org/stable/calligra-2.8.7/calligra-2.8.7.tar.xz > I thought it's a direct link. > How is mirror selected for that? Based on a number of geographical criteria. IP Netblock, ASN, GeoIP co-ordinates, etc. > > >>> Apps such as KDevelop don't seem to do that. >> >> >> -- >> Cyrille Berger Skott Cheers, Ben >> ___ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel > > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.9 Changelog
On Thu, Feb 26, 2015 at 10:23 PM, Jaroslaw Staniek wrote: > On 26 February 2015 at 10:15, Ben Cooksley wrote: >> On Thu, Feb 26, 2015 at 10:01 PM, Jaroslaw Staniek wrote: >>> On 26 February 2015 at 08:31, Cyrille Berger wrote: >>>> On 2015-02-25 15:13, Jaroslaw Staniek wrote: >>>>> >>>>> Thanks. I have one question @Cyrille. >>>>> Why are the previous binaries removed (not just 2.8.0 but also 2.8.6?). >>>> >>>> When moving to the next major release, I always only keep the last minor >>>> release of the previous one. The reason is to keep the mirrors small. >>> >>> OK >> >> I wouldn't worry about using mirror disk space. Sysadmin moves stuff >> into the Attic as needed. >> I do hope you've been moving to the Attic and not rm -rf'ing them... > > Cool. WiIl the original directory stay so URLs work as before, e.g. > internally using symlinks? > I guess not only calligra.org links there but some external sites. Theoretically you could symlink it. Usually we just move it entirely though. The policy with regards to old content tends to be allowing current major + at least one (if not more) prior major versions, as well as all relevant patch releases. > > @Cyrille so.. can we switch to this policy for now? > >>> >>>>> Now users/packagers have no access to previous versions e.g. and links >>>>> on previous announcements are now broken. This looks rather >>>>> unprofessional. >>>> >>>> >>>> What we should probably do is to edit the download link then. And replace >>>> it >>>> with links to the tag. >>> >>> Sure, while we're in a computer era, any idea how to make it automatic? >> >> Please don't use links to the tag tarballs produced by >> quickgit.kde.org - that will create undue burden. > > yeah > >> >>> >>> We're putting links like >>> http://download.kde.org/stable/calligra-2.8.7/calligra-2.8.7.tar.xz >>> I thought it's a direct link. >>> How is mirror selected for that? >> >> Based on a number of geographical criteria. IP Netblock, ASN, GeoIP >> co-ordinates, etc. > > Good, in the old times user were confronted with mirror selection IIRC. This depends on the url you are publishing - you'll still get such a page if you were to visit http://download.kde.org/stable/calligra-2.8.7/calligra-2.8.7.tar.xz.mirrorlist (Note the .mirrorlist) Links without the .mirrorlist will result in a redirect to your nearest mirror, unless there isn't one in which case we directly serve it. Cheers, Ben > >>> >>> >>>>> Apps such as KDevelop don't seem to do that. >>>> >>>> >>>> -- >>>> Cyrille Berger Skott >> >> Cheers, >> Ben >> >>>> ___ >>>> calligra-devel mailing list >>>> calligra-devel@kde.org >>>> https://mail.kde.org/mailman/listinfo/calligra-devel >>> >>> >>> >>> -- >>> regards, Jaroslaw Staniek >>> >>> KDE: >>> : A world-wide network of software engineers, artists, writers, translators >>> : and facilitators committed to Free Software development - http://kde.org >>> Calligra Suite: >>> : A graphic art and office suite - http://calligra.org >>> Kexi: >>> : A visual database apps builder - http://calligra.org/kexi >>> Qt Certified Specialist: >>> : http://www.linkedin.com/in/jstaniek > > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: [Kexi-devel] Preview of astyle-kdelibs changes up in a branch (was: Re: [Port blocker] Re: RFC: plan for starting the Qt5/KF5 port)
On Thu, Mar 5, 2015 at 12:56 AM, Jaroslaw Staniek wrote:
> Nice thanks.
> I see 28% of changes are non-whitespace.
> Forcing {} for if/else is good.
>
> Could we please exclude dirs that contain forked code that would be
> compared to external copies?
> One comes to my mind: kexi/migration/mdb/src/mdbtools/. Anything else?
>
> For the future I'd use the tool as a local pre-commit hook.
>
> For stats I recommend using the following author in this commit, I
> hope there are commit rights:
> astyle-kdelibs
Please don't abuse scripty for this.
Simply commit the re-styling of the code as yourself, it won't pose any issue.
>
> @Ben?
>
> Similar for other scripts.
Regards,
Ben
>
> On 4 March 2015 at 12:23, Friedrich W. H. Kossebau wrote:
>> Am Mittwoch, 4. März 2015, 00:10:28 schrieb Friedrich W. H. Kossebau:
>>> Am Dienstag, 3. März 2015, 23:37:02 schrieb Jaroslaw Staniek:
>>> > First let's verify if astyle-kdelibs changes only whitespace.
>>>
>>> Okay, I propose that we wait with the porting start until this got sorted
>>> out.
>>>
>>> No pressing need to really start porting today, 2-3 more days don't hurt
>>> here, and there are enough bugs to fix for 2.9. Better have all maintainers
>>> aligned in the goals.
>>> Most people have more time only at the WE anyway :)
>>>
>>> Kicked off a qt5 build for the night to hopefully get that "normalize" tool,
>>> might give a diff some testing tomorrow afternoon.
>>
>> I found meanwhile that the normalize tool can be compiled on its own, is not
>> part of the actual Qt build. So I did, and with the patched astyle ran
>> astyle-
>> kdelibs on this morning's Calligra master.
>>
>> Please see the result committed as branch for preview to the central repo,
>> with 3rd-party, libs/{db,koreport,koproperty}, plugins/reporting not touched,
>> (because either going to be removed or 3rd-party):
>>
>> astyle-kdelibs-result-2015-03-04-kossebau
>>
>> Would those changes work for everyone? Please give feedback as quickly as
>> possible, so you are heard.
>> (The branch will be deleted later on, just used for convenience to have
>> everyone see the possible changes.)
>>
>> Cheers
>> Friedrich
>>
>> ___
>> Kexi-devel mailing list
>> kexi-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/kexi-devel
>
>
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Question about Calligra branches for Phabricator revisions
On Sat, Jun 20, 2015 at 10:47 AM, Jaroslaw Staniek wrote: > On 18 June 2015 at 10:30, Boudewijn Rempt wrote: >> On Thu, 18 Jun 2015, Jaroslaw Staniek wrote: >> >>> Hi, >>> We started to use/try phabricator for reviews, task management [1]. >>> During the KDE admins, namely Ben Cooksley, are more than helpful to >>> tune things up to our workflows. >>> >>> The difference between it and the reviewboard.kde.org in that >>> 'autocloses' revews (so-called revisions [2]) when a commit containing >>> a 'Differential Revision:' line [3] in its message is pushed to the >>> repo. This means immediate closing of the review. But we tend to push >>> to a feature branch for facilitate code management: I personally would >>> not want to keep commits locally and only publish diffs on phabricator >>> during the review. >>> >>> After some chatting with Ben we have an idea that the auto-closing is >>> good but it could be limited to some branches. >>> >>> Now the question is what these branches are for the calligra repo. >>> My idea is: master, calligra/x.y. And maybe frameworks? >> >> >> I think that's a good list. Frameworks needs to be included, since it looks >> like it'll be living for some time yet. >> > > @Ben I think the list is complete: master, calligra/x.y, frameworks. It should now be configured to do so. Autoclose Only: master, frameworks, regexp(/^calligra\//) Regards, Ben >> >>> >>> Please comment on it within the 48h or so. >>> >>> PS: For new repos I am managing - kreport/kproperty/kdb - it's enough >>> to have autoclose is only for master. >>> PS: I know most can be lost as there's no official >>> Calligra/KDE-specific HOWTO for the phabricator-based workflow; we >>> need to have it all working for us first before recommending. >>> >>> [1] http://phabricator.kde.org/ >>> [2] https://secure.phabricator.com/book/phabricator/article/differential/ >>> (nice command-line function available using arcanist) >>> [3] Example of such a commit: >>> http://comments.gmane.org/gmane.comp.kde.cvs/1421533 >>> -- >>> regards, Jaroslaw Staniek >>> >>> KDE: >>> : A world-wide network of software engineers, artists, writers, >>> translators >>> : and facilitators committed to Free Software development - http://kde.org >>> Calligra Suite: >>> : A graphic art and office suite - http://calligra.org >>> Kexi: >>> : A visual database apps builder - http://calligra.org/kexi >>> Qt Certified Specialist: >>> : http://www.linkedin.com/in/jstaniek >>> ___ >>> calligra-devel mailing list >>> calligra-devel@kde.org >>> https://mail.kde.org/mailman/listinfo/calligra-devel >> >> ___ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel > > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Question about Calligra branches for Phabricator revisions
On Mon, Jun 22, 2015 at 7:18 AM, Jaroslaw Staniek wrote: > On 21 June 2015 at 10:44, Ben Cooksley wrote: >>> >>> @Ben I think the list is complete: master, calligra/x.y, frameworks. >> >> It should now be configured to do so. >> Autoclose Only: master, frameworks, regexp(/^calligra\//) > > Ben, thanks! > One thing that probably needs clarification. From the ticket TNK-3382, > your note: > > "Per my email this should now be resolved. > In regards to Arcanist, you can probably configure it to not add the > "Differential Revision" line." > > I'd like to ask what does it mean. What this means is: a) I've configured the autoclose branches as requested. b) For future reference, Arcanist can probably be configured to not alter the commit message when landing commits. This would avoid autoclosing if you don't want to when landing into an autoclose branch. > > My assumption was that the line can be added (by hand or by Arcanist > or any such tool) to the commit message and still the non-autoclosing > branches won't react (the Differential won't close the review). > Regards, Ben > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Phabricator & commit spells
On Wed, Jul 8, 2015 at 7:55 AM, Jaroslaw Staniek wrote: > Hi, Hi Jaroslaw, > I am not sure this is a part of docs already, gogole does not confirms > this. So putting here: > "Special commands in comments can cause various effects, like closing > a related task when a commit is pushed." > > https://secure.phabricator.com/T5132#69200 > > What do you think? Are these spells useful? They function similarly to our existing hooks, and considering they'll be enabled by default I don't see why we would want to change that :) > > -- > regards, Jaroslaw Staniek Cheers, Ben > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Handling of splitted Calligra repos and API changes
On Mon, Aug 31, 2015 at 12:29 PM, Jaroslaw Staniek wrote:
> On 31 August 2015 at 01:46, Friedrich W. H. Kossebau wrote:
>> Am Sonntag, 30. August 2015, 23:21:59 schrieb Jaroslaw Staniek:
>>> On 28 August 2015 at 19:10, Friedrich W. H. Kossebau
>> wrote:
>>> > Hi,
>>> >
>>> > with KDb, KProperty and KReport, a few libs/frameworks have been already
>>> > split off during the port of Calligra to Qt5/KF5.
>>> >
>>> > And they pose a challenge that needs to be solved quickly:
>>> > traditionally we have had no ABI guarantuee in Calligra even in patch
>>> > releases and of course also not during development. Because sourcecode of
>>> > all libs and libconsumers were in a shared repo, and any API changes were
>>> > done in atomic commits both to the libs and libconsumers (because by
>>> > policy we require any commits to the repo to not break it's build).
>>> >
>>> > With libs and libconsumers being split in separate repos the atomicity no
>>> > longer is given.
>>> >
>>> > Which results in problems:
>>> > * people might pull from repos missing part of API change commits
>>> > * current KDE CI triggered by commits will build repos without caring for
>>> >
>>> > dependencies between commits, using products from previous lib builds
>>> > with
>>> > old API for the build of libconsumer with commit using newer API
>>> >
>>> > * ?
>>> >
>>> > No idea how to solve the KDE CI one perfectly. But for the problem of
>>> > pulling consistent states, what about the following rules with the split
>>> > off lib repos:
>>> > * no ABI breakage in patch releases for released branches
>>> > * weekday of API breakage: a set day per week development branches can get
>>> >
>>> > commits which involve API changes in the libs in separate repos
>>> > still related commits should be pushed together in an as small
>>> > timewindow
>>> > as possible
>>> >
>>> > No ABI breakage in patch releases might be a no-brainer, given that
>>> > targetted 3rd-party consumers would rely on that as well.
>>> > The second one would pick up something which seemed to work well enough in
>>> > times where close kdelibs and kdeapps development was common, and where
>>> > people also did separate svn "pulls" for libs and apps. Pushing related
>>> > commits to all repos in small timewindows might not completely match
>>> > atomic commits as possible with subversion. But in the end we all pull in
>>> > time ("fetch latest commits now") and not by branch state ("fetch commits
>>> > until xyz id"), so in practice this might work as well still.
>>> >
>>> > What do you think? Would this work for you as well?
>>> >
>>> > IMHO we need to have an agreed solution here before Kexi-frameworks is
>>> > merged back, because it will force us into this situation (where Plan
>>> > currently does not depend on KReport, my respective patch waiting since
>>> > many weeks for someone to push this question for handling of the
>>> > API-break challenge and to find an agreed resolution ;) ).
>>> >
>>> > ((While in the discussion this is only about those 3 libs for now... My
>>> > personal desire is to make the Calligra document libs more accessible to
>>> > other apps, which partially do document creating/processing. For that I
>>> > would see some advantage to split off more libs into own repos as well.
>>> > In the long run I would like to see Calligra move out of it's own corner
>>> > and integrate more with the normal KDE application scene.
>>> > But more on that once we have finally passed the port hurdle, are back in
>>> > normal feature development and can start talking post-3.0 (where 3.0 is
>>> > now
>>> > the first real release) :) ))
>>
>> > depart from usual handling>
>>
>>> Next, how to check versions. A single properly configured kdesrc-build
>>> can solve issues when people try to fetch individual repos and make
>>> human mistakes.
>>> During development you either use kdesrc-build configured to use the
>>> branch for the repos (e.g. master)
>>
>> I see a problem here:
>> right now everony for the everyday development on the development branch (so
>> not stable/release branches) does a "git pull" or "git pull --rebase" before
>> pushing ones own commits. Because when your patch is ready to be pushed, you
>> want to get it out and then do something else. Which you can do now.
>> Using instead kdesrc-build or similar tools every time will add cost more
>> time
>> during that process. And even some seconds already are annoying, when they do
>> not improve your developing experience. Worse, if the tool detects a new
>> commit in one of the repos and starts a rebuild of that, perhaps even a full
>> because some central header was touched, you will lose even more time and be
>> even more annoyed. No, I do not see me using something which checks all repos
>> every time I do now a "git pull". And very possibly also not anyone else.
>> On a certain day per week, where I can expect breakage, sure. But not 24/7.
>
> Todays scenario:
> "Before pushing I am not j
Upcoming downtime notification: cano.kde.org
Hi all, Just a quick notice that in order to allow for a move between data centers, there will be downtime for the server cano.kde.org on Saturday 18th August. This will begin at approximately 09:00 UTC and may last up to 12 hours (i.e. until 19:00 UTC). The following websites will be affected: - dot.kde.org - forum.kde.org - userbase.kde.org - techbase.kde.org - community.kde.org - blogs.kde.org, uwg.kde.org - nepomuk.kde.org, k3b.kde.org, discover.kde.org - akademy2012.kde.org, akademy2010.kde.org, akademy.kde.org, wiki.akademy.kde.org - www.calligra.org, www.behindkde.org - www.desktopsummit.org, wiki.desktopsummit.org - kde.in, ir.kde.org, br.kde.org Other services will not be affected by this downtime. Regards, Ben Cooksley KDE Sysadmin ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Upcoming downtime notification: cano.kde.org
Hi all, Just a quick reminder of the previously announced downtime: In order to allow for a move between data centers, there will be downtime for the server cano.kde.org on Saturday 18th August. This will begin at approximately 09:00 UTC and may last up to 12 hours (i.e. until 19:00 UTC). The following websites will be affected: - dot.kde.org - forum.kde.org - userbase.kde.org - techbase.kde.org - community.kde.org - blogs.kde.org, uwg.kde.org - nepomuk.kde.org, k3b.kde.org, discover.kde.org - akademy2012.kde.org, akademy2010.kde.org, akademy.kde.org, wiki.akademy.kde.org - www.calligra.org, www.behindkde.org - www.desktopsummit.org, wiki.desktopsummit.org - kde.in, ir.kde.org, br.kde.org Other services will not be affected by this downtime. Regards, Ben Cooksley KDE Sysadmin ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Junior Job: "KDE - Office" page and subpages still not enough updated since switching to Calligra
On Mon, Mar 17, 2014 at 11:43 AM, Jaroslaw Staniek wrote: > Hi, Hi Jaroslaw, > The Office page and subpages still not updated after switching to Calligra: > > http://www.kde.org/applications/office > > Namely: > KSpread is now Sheets > Kivio is now Flow > KPlato is now Plan > KWord is now Words > KPresenter is now Stage > > Moreover: > - Some of these pages refer to KOffice by name, mailing list name and > irc channel name, forum, etc. this also needs fixing. > > - Screenshots could be updated too (can be grabbed from calligra.org) > > It's a junior job, is anyone interested to help out? While I don't have the time to actually make the change, i'm familiar with how the main kde.org site is setup, so can assist anyone with that. > > PS: I am sending this in light of the fact that since March 1, 2011 > (2.3.3) newer versions of KOffice have not been officially released. > Thanks, Ben > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek > ___ > kde-www mailing list > kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-www ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Junior Job: "KDE - Office" page and subpages still not enough updated since switching to Calligra
-- Forwarded message -- From: "Ben Cooksley" Date: Mar 17, 2014 7:24 PM Subject: Re: Junior Job: "KDE - Office" page and subpages still not enough updated since switching to Calligra To: "kde-www" Cc: On Mon, Mar 17, 2014 at 6:15 PM, Ahmed Fathy Hussein wrote: > > On Mar 17, 2014 6:45 AM, "Ben Cooksley" wrote: >> >> On Mon, Mar 17, 2014 at 11:43 AM, Jaroslaw Staniek >> wrote: >> > Hi, >> >> Hi Jaroslaw, >> >> > The Office page and subpages still not updated after switching to >> > Calligra: >> > >> > http://www.kde.org/applications/office >> > >> > Namely: >> > KSpread is now Sheets >> > Kivio is now Flow >> > KPlato is now Plan >> > KWord is now Words >> > KPresenter is now Stage >> > >> > Moreover: >> > - Some of these pages refer to KOffice by name, mailing list name and >> > irc channel name, forum, etc. this also needs fixing. >> > >> > - Screenshots could be updated too (can be grabbed from calligra.org) >> > >> > It's a junior job, is anyone interested to help out? >> >> While I don't have the time to actually make the change, i'm familiar >> with how the main kde.org site is setup, so can assist anyone with >> that. >> > > I think I can handle this later tonight. Could you send me details on how to > edit the main website? The main website is located at svn+ssh://s...@svn.kde.org/home/kde/trunk/www/sites/www/ In particular though, you're only interested in the applications/ folder. Within that, you will find an apps/ folder containing a series of JSON files. You'll need to rename the KOffice related files (both appname.json and appname_generated.json) as well as add any new files which are required, and edit them to contain the correct details. The screenshot for each application can be found at images/screenshots, and the application icons at images/icons. Once you've made your changes, from the applications/ folder run the following command: python extractappdata/extractappdata.py --build-index Finally, post the patch for me to review - as special permissions are required to commit to the primary kde.org website. > >> > >> > PS: I am sending this in light of the fact that since March 1, 2011 >> > (2.3.3) newer versions of KOffice have not been officially released. >> > >> >> Thanks, >> Ben Thanks, Ben >> >> > -- >> > regards / pozdrawiam, Jaroslaw Staniek >> > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >> > Qt for Tizen | http://qt-project.org/wiki/Tizen >> > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek >> > ___ >> > kde-www mailing list >> > kde-...@kde.org >> > https://mail.kde.org/mailman/listinfo/kde-www >> ___ >> kde-www mailing list >> kde-...@kde.org >> https://mail.kde.org/mailman/listinfo/kde-www > > > ___ > kde-www mailing list > kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-www > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Junior Job: "KDE - Office" page and subpages still not enough updated since switching to Calligra
On Mar 18, 2014 1:13 AM, "Ionel Popescu" wrote: > > Hello, Hi Ionel, > > I would like to help you with this job. > > Ben, I would be grateful if you could provide me some details about the site kde.org setup. I've now forwarded a mail containing the necessary details to the calligra mailing list. If you need any other details please let me know. > > > Thank you, > Ionel Popescu Thanks, Ben > > > > 2014-03-17 6:45 GMT+02:00 Ben Cooksley : >> >> On Mon, Mar 17, 2014 at 11:43 AM, Jaroslaw Staniek wrote: >> > Hi, >> >> Hi Jaroslaw, >> >> > The Office page and subpages still not updated after switching to Calligra: >> > >> > http://www.kde.org/applications/office >> > >> > Namely: >> > KSpread is now Sheets >> > Kivio is now Flow >> > KPlato is now Plan >> > KWord is now Words >> > KPresenter is now Stage >> > >> > Moreover: >> > - Some of these pages refer to KOffice by name, mailing list name and >> > irc channel name, forum, etc. this also needs fixing. >> > >> > - Screenshots could be updated too (can be grabbed from calligra.org) >> > >> > It's a junior job, is anyone interested to help out? >> >> While I don't have the time to actually make the change, i'm familiar >> with how the main kde.org site is setup, so can assist anyone with >> that. >> >> > >> > PS: I am sending this in light of the fact that since March 1, 2011 >> > (2.3.3) newer versions of KOffice have not been officially released. >> > >> >> Thanks, >> Ben >> >> > -- >> > regards / pozdrawiam, Jaroslaw Staniek >> > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org >> > Qt for Tizen | http://qt-project.org/wiki/Tizen >> > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek >> > ___ >> > kde-www mailing list >> > kde-...@kde.org >> > https://mail.kde.org/mailman/listinfo/kde-www >> ___ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
[Maniphest] [Commented On] T3755: Kexi API docs missing in the calligra section
bcooksley added a comment. At this point i'd suggest simply going ahead with the short term pain, long term gain method of adopting KApiDox for building your API Documentation, as the legacy scripts and mechanisms are fragile - I certainly don't want to touch them. TASK DETAIL https://phabricator.kde.org/T3755 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: bcooksley Cc: piggz, kossebau, Calligra-Devel-list, bcooksley, ochurlaud, sysadmin, staniek, blazquez
[Differential] [Changed Policy] D183: Add library export definitions
bcooksley changed the visibility of this Differential Revision from "All Users" to "Public (No Login Required)". REPOSITORY rCALLIGRA Calligra REVISION DETAIL https://phabricator.kde.org/D183 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: abrahams, dkazakov, staniek, rempt, kossebau Cc: Calligra-Devel-list, staniek, kossebau ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
