Bug#879741: next steps / request for help with phpmyadmin for debian buster
On Wed, May 29, 2019 at 10:59 AM Blümel Matthias < matthias.blue...@krumedia.com> wrote: > Here we go: unit-tests are back in debian/rules :D. > > I'm stuggling at the moment with my setup for selenium-tests. This has > nothing to do with package-related suff, the tests on a git-checkout > are also failing. > > As long as I can see, the unit-tests are only testing basic stuff. > There seems to be nothing with twig-templates, shapefiles, 2fa, pdf- > export, … > > Tomorrow is public holiday in Germany, but I already "catched" one of > our trainees for testing the package and it's dependencies starting on > friday. > > @felipe: can you enable the issues-feature on the project? Sorry for the delay, done now. > Are you fine > with the way I mentioned in comment #62 to update to the current > version? If so, who triggers the update? Am I able to push to master > with the "developer"-role? > Yes, the developer role should be sufficient. Should any permission be missing, just tell me. I think the best plan is what you outlined: > Make a new update to 4.8.5 based on master and rebase the work currently laying around in three repositories? I also have some patches I didn't push so I guess they make more sense to apply on top (if still needed). > What do you think is the best way to get the changes into the main project? pushing directly to master? pushing to a new branch? making a PR? I think PRs are best for changes that require input from others. Unfortunately, they are not very good for the upstream/pristine-tar/master trio needed for a new upstream update. So I think upstream updates should go directly to master. I think most teams push directly to master. After all, a revert is not that difficult to do in case a commit was not ok :) -- Saludos, Felipe Sateler
Bug#879741: next steps / request for help with phpmyadmin for debian buster
Here we go: unit-tests are back in debian/rules :D. I'm stuggling at the moment with my setup for selenium-tests. This has nothing to do with package-related suff, the tests on a git-checkout are also failing. As long as I can see, the unit-tests are only testing basic stuff. There seems to be nothing with twig-templates, shapefiles, 2fa, pdf- export, … Tomorrow is public holiday in Germany, but I already "catched" one of our trainees for testing the package and it's dependencies starting on friday. @felipe: can you enable the issues-feature on the project? Are you fine with the way I mentioned in comment #62 to update to the current version? If so, who triggers the update? Am I able to push to master with the "developer"-role? Grüße Matthias Am Mittwoch, den 29.05.2019, 07:54 +0200 schrieb Michal Čihař: > Hi > > There are phpunit tests including Selenium ones. Running unit tests > should be quite easy to achieve and should verify that PHP code works > well, for the Selenium tests the setup would be probably more complex > to do (it should be possible with the chromium-driver package, but I > have no experience here). > > See upstream script for execution examples: > > https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_8/test/ci-test > > > https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_8/test/ci-selenium > >
Bug#879741: next steps / request for help with phpmyadmin for debian buster
Hi On Tue, 2019-05-28 at 10:55 -0400, Felipe Sateler wrote: > > On Tue, May 28, 2019 at 10:30 AM Blümel Matthias < > matthias.blue...@krumedia.com> wrote: > > > > Does phpmyadmin have any test plans for integration and/or > > acceptance-tests to check if its features are still working with > > the package installation? (I don't care how long processing of this > > would take, we have trainees :p ) > > > > This would be very nice to have, implemented as autopkgtests. Maybe > Michal Cihar can guide here? There are phpunit tests including Selenium ones. Running unit tests should be quite easy to achieve and should verify that PHP code works well, for the Selenium tests the setup would be probably more complex to do (it should be possible with the chromium-driver package, but I have no experience here). See upstream script for execution examples: https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_8/test/ci-test https://github.com/phpmyadmin/phpmyadmin/blob/QA_4_8/test/ci-selenium -- Michal Čihař | https://cihar.com/ | https://weblate.org/ signature.asc Description: This is a digitally signed message part
Bug#879741: next steps / request for help with phpmyadmin for debian buster
Am Dienstag, den 28.05.2019, 10:55 -0400 schrieb Felipe Sateler:
I usually use the very nice helper gbp-pq. I usually prefer proper patches
because it makes it easier to push them upstream. I usually don't want to
maintain forks :)
yeah, I used `gpb import-orig --uscan` to update to 4.8.5 which was very nice
and easy. What I'm not sure about are things like the correct contents of the
changelog file, when to use which version-suffix, the correct way of handling
debian/patches, when to tag with wich name, etc.
TWIG is a templating library. That means the html views are not rendered
directly with php, but rather via a less powerful language. The idea, as I
understand it, being that views should have little to no logic, and such
templating libraries help enforce that rule.
But where is it used in phpmyadmin ;)
I can help you with that. As my activity has shown, though, I'm not being able
to dedicate much time. I can, however, do some testing, and help with uploading.
Nice to read :)
Is there any way to keep track of the progress in a collaborative way better
than sending emails? I'd propose working with issues on salsa.
Sounds good to me.
Can you enable issues on the project? I'd like to start with some issues for
every new or changed dependency to test if it's still working like it shoud.
Furthermore I would make issues for "upload package to
{experimental,sid,buster-backports}" depending on each other, so we can add new
issues as blockers if someone finds bugs or something else is to do.
What do you think is the best way to get the changes into the main project?
pushing directly to master? pushing to a new branch? making a PR? How about the
branches 'upstream' and 'pristine-tar'? 1 PR for each branch? Make a new update
to 4.8.5 based on master and rebase the work currently laying around in three
repositories? … We should make an issue to discuss that :D
(I think a fresh update and rebasing the work is the cleanest way. The history
with all these merges and conflicting changes between gratuxri/master,
fsateler/master and now my own one ist unclean, confusing and not necessary.)
Viele Grüße
Matthias
Bug#879741: next steps / request for help with phpmyadmin for debian buster
Hello Matthias, On Tue, May 28, 2019 at 10:30 AM Blümel Matthias < matthias.blue...@krumedia.com> wrote: > Hey Guys, > > I've seen, you made some progress recently on the phpmyadmin-package on > salsa. I've cloned the repository for myself, merged the work from your > personal forks and made another update to 4.8.5 ( > https://salsa.debian.org/blaimi-guest/phpmyadmin). > Cool. > The package seem to work as in "works on my machine" on my local > buster-installation with the packaged dependencies from the phpmyadmin-team > on salsa and tcpdf from sid (with a little fix > https://salsa.debian.org/phpmyadmin-team/shapefile/merge_requests/1) > Thanks for this. Merged. > > I'm familiar with building packages in source-format but not that familiar > with the overhead of quilt-format. > I usually use the very nice helper gbp-pq. I usually prefer proper patches because it makes it easier to push them upstream. I usually don't want to maintain forks :) > My phpmyadmin-skills are also very limited and concentrate on using its > basic features like manipulating table-contents and im-/export. > Coincidentally I know how to work with shapefiles but I have no idea how > they are used in phpmyadmin. > Neither do I. > Does phpmyadmin have any test plans for integration and/or > acceptance-tests to check if its features are still working with the > package installation? (I don't care how long processing of this would take, > we have trainees :p ) > This would be very nice to have, implemented as autopkgtests. Maybe Michal Cihar can guide here? > I also do not (yet) know what twig is used for and how to test it.(I've > read some thing about formatting columns with currency-values?) > TWIG is a templating library. That means the html views are not rendered directly with php, but rather via a less powerful language. The idea, as I understand it, being that views should have little to no logic, and such templating libraries help enforce that rule. > BTW: twig is upgraded in master on upstream. Besides the composer.json > only some twig-cache-generator is touches which does not exist in 4.8 ( > https://github.com/phpmyadmin/phpmyadmin/commit/1c097a90eb8430a0445886b1849935e0e3e603bf > ) > > So, what I request is some help in the "political" stuff around the > debian-packaging, i.e. about the todos on getting phpmyadmin available in > sid (and hopefully in buster-backports as soon as it is available), as well > as help in testing the package. I should be able to fix stuff in the > package as long as I know about its defects. > I can help you with that. As my activity has shown, though, I'm not being able to dedicate much time. I can, however, do some testing, and help with uploading. > Is there any way to keep track of the progress in a collaborative way > better than sending emails? I'd propose working with issues on salsa. > Sounds good to me. I have given you access to the team, so that you can push these directly. -- Saludos, Felipe Sateler
Bug#879741: next steps / request for help with phpmyadmin for debian buster
Hey Guys, I've seen, you made some progress recently on the phpmyadmin-package on salsa. I've cloned the repository for myself, merged the work from your personal forks and made another update to 4.8.5 (https://salsa.debian.org/blaimi-guest/phpmyadmin). The package seem to work as in "works on my machine" on my local buster-installation with the packaged dependencies from the phpmyadmin-team on salsa and tcpdf from sid (with a little fix https://salsa.debian.org/phpmyadmin-team/shapefile/merge_requests/1) I'm familiar with building packages in source-format but not that familiar with the overhead of quilt-format. My phpmyadmin-skills are also very limited and concentrate on using its basic features like manipulating table-contents and im-/export. Coincidentally I know how to work with shapefiles but I have no idea how they are used in phpmyadmin. Does phpmyadmin have any test plans for integration and/or acceptance-tests to check if its features are still working with the package installation? (I don't care how long processing of this would take, we have trainees :p ) I also do not (yet) know what twig is used for and how to test it.(I've read some thing about formatting columns with currency-values?) BTW: twig is upgraded in master on upstream. Besides the composer.json only some twig-cache-generator is touches which does not exist in 4.8 (https://github.com/phpmyadmin/phpmyadmin/commit/1c097a90eb8430a0445886b1849935e0e3e603bf) So, what I request is some help in the "political" stuff around the debian-packaging, i.e. about the todos on getting phpmyadmin available in sid (and hopefully in buster-backports as soon as it is available), as well as help in testing the package. I should be able to fix stuff in the package as long as I know about its defects. Is there any way to keep track of the progress in a collaborative way better than sending emails? I'd propose working with issues on salsa. Best greetings from Karlsruhe and many thanks for the work you all have already done Matthias -- krumedia GmbH - "IT for energy" Rommelstraße 1 76227 Karlsruhe Tel. +49 721 942697-0 www.krumedia.com Registergericht Mannheim HRB8996 Umsatzsteueridentifikationsnummer: DE204437524
