#wine-staging

The moon!

austin987: ping?

mogorva: ping

slackner, pong :)

mogorva: i saw that you already started moving bug reports, and was wondering a bit how to do this in a way such that we can easily keep track of the progress

i think we should either close the bugs in our bug tracker or set the upstream bug url

we definitely also need back references

from the winehq bugtracker to the wine-staging bugtracker, where additional comments might be present

since it is only temporary, I would suggest to just include a link inside a comment

austin987 also did not all of the changes we discussed, hopefully this can be fixed soon before its too late and getting a huge mess

i.e. "Migrated from ..."

i thought you would close the staging bugtracker eventually so i didn't link any of those bugs

i expect it to stay in read only mode for some while

mogorva: the idea is to do all this step by step, only new bug reports will be blocked soon (after i have figured out how to do that)

slackner: you can just remove the "Open for bug entry" status from the wine staging product

we also need to specifiy the new ways of patch submissions before can do this

mogorva: i have just added a new resolution "MIGRATED" to our bugtracker. i would suggest the following procedure: when you migrate one of your bugs, create the new WineHQ report with reference to the wine-staging bugtracker. then code the staging bugreport with RESOLVED MIGRATED. if possible always mention a reference in both directions

slackner, roger that

... i only hope that the newly introduced upstream status RESOLVED {STAGED,NEEDSINFO} is not used that much, until austin987 has a chance to look at my mail ... :| the original idea was something different i think ...

slackner, shall i close all of my upstream bugs reported in staging bugtracker?

i think we can close all bugs that do not contain any additional comments

for the others bugs we need to check if it makes sense to migrate the information to upstream

yeah, for bugs with additional comments / analysis someone has to take a look manually, to decide if its worth mentioning them in the upstream bugtracker

mogorva: btw, if you are wondering: i do not care where the bug# is mention, just wanted to add a reference to the four bugs you opened earlier ;)

*mentioned

mogorva: i would suggest to use the RESOLVED MIGRATED status even for upstream bugs which are no longer necessary

slackner, i see, k

hackomatic: could you also answer that to the mailing list... very good point

mogorva: hackomatic just pointed out in https://bugs.winehq.org/show_bug.cgi?id=39353 that we currently can't properly migrate version information ... :/

04Bug 39353: normal, P2, ---, wine-bugs, NEW , Wine-staging product in bugzilla needs to have same version information field as Wine

mogorva: so we might have to fix that manually afterwards

slackner: I was hoping that this is an obvious and trivial thing to add, and therefore it doesn't need another round of "discussions" on wine-devel

hackomatic: well, would be good to fix this as soon as possible, otherwise it will be a mess to fix all the existing reports

slackner: I'd suggest to hold on the migration until that gets fixed

mogorva: ^

and add a comment to that bug report

that further migration depends on it

mogorva: things which can be closed on our bugtracker without creating new bug reports in the staging category can still be ported of course

slackner, pong

austin987: ah, wb :) see my mail on wine-devel

slackner, I can add the version numbers, that's not a ton of work, but the components would be a pain (I thought you had talked to AJ about doing a database trick for that)

austin987: i think hackomatic was mainly concerned about the missing version numbers

slackner, I'll fix that now

austin987: kk.

austin987: also, do you want to keep STAGING and NEEDSINFO as RESOLVED status? i think it would make more sense as unresolved status

usually RESOLVED means its a final solution (well, at least it implies that for me)

slackner, I'm fine with changing it, I hadn't thought about it that closely, your view makes sense to me

i also think that we decided that STAGING shouldn't be a resolved status

very possible but I missed that (not in my notes in any case), but simple enough to change

austin987: yeah, luckily not used by anyone yet, otherwise it would be more complicated ;)

austin987: what do you think about the idea, to add a new field "Staged patchset" or something like that, which only appears for bugs with the STAGED status?

(kinda optional, but might be better than writing always a new comment when something changes)

slackner, what are you intending to put in that field?

austin987: URL to the staging patchset / patch

(mainly for developers, so that they can find the latest version easily)

slackner, makes sense to me

slackner / DarkPlayer, you should now be able to edit keywords/etc. (DarkPlayer, you can also now confirm/edit bugs)

thx :)

you should've pinged me earlier, I didn't realize you couldn't edit/confirm bugs :)

austin987: just saw it, thx :-)

(that applies to any developer)

austin987: do you know how julliard adds the new versions? i'm asking because it would also be nice to automate the synchronization of staged patches

austin987: when setting the STAGED status manually it could quickly get out of sync with the patches from our repo

slackner, I do not

austin987: what about the Component field?

hackomatic: there was a discussion if we can somehow keep it in sync with the wine product

hackomatic: but not completely sure if the component is that important

mogorva: version field fixed, you can continue ;)

slackner: I think it is

slackner: basically wine-staging should not have any difference from wine in the bugzilla except the product name

so one could easily move the bugs from one to another if needed

hackomatic: well, there is one difference: the staging product should only contain regressions

hackomatic: which means, the component might not even be present in Wine

(for new features)

slackner: that's a minor detail :)

hackomatic: well, it depends a bit. If we we want to allow patch submission via the bug tracker, than it would make sense to break with the concept and add the components: regressions / patch submission

DarkPlayer: isn't that already covered by keywords?

so far wine-staging is only for regressions

there is no formal way what a developer should do if his patchs gets rejected with the status STAGING

well, if somebody assigns wrong product by a mistake it should be trivial to change that without changing anything else

DarkPlayer: keyword 'patch' supposedly was invented exactly for that reason

hackomatic: no, WineHQ doesn't use the bugtracker for patch submissions

hackomatic, unfortunately I don't see any easy way to share components across products

there are a lot of patches which are just hacks

slackner: yes, but the keyword 'patch' indicates that there is a patch for the being reported problem

if someone wants to add a patch to wine staging, it should be more clear