[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Reply to: