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

Re: wine-unstable in Debian

Please note that in the following I'm solely trying to help all involved, and 
that none of the below is meant to be criticism -- so if any is implied, that 
is strictly unintentional.

On Tuesday, April 17, 2012 13:17:45, Stefano Zacchiroli wrote:
> On Sun, Apr 15, 2012 at 03:07:54PM -0400, Chris Knadle wrote:
> > C) Current WINE maintainers are either MIA or time overload elsewhere.
> > Volunteers trying to help who have made additional 1.1.x packages are
> > stuck waiting because they do not have access to the pkg-wine git repo.
> Just to nitpick a bit on the above, Cc:-ing the maintainer, which seems
> a fair thing to do given the topic of this discussion. The current
> maintainer did reply to at least a couple of the inquiries in the buglog
> and does not appear to be MIA.

Correct -- not MIA, but he went through his time overload and priorities, such 
that he doesn't have time to work on the wine packages -- and I did say 
"either MIA or time overloaded" :-P.  Unfortunately Ove did not say when his 
time overload is likely to change, so there is currently no expectation that 
it will.

> He has, however, some specific requirements on the work that he wants
> to be done before granting commit access to the Git repository. That
> is his prerogative.

That would be fine, except that he doesn't have time to get someone else up to 
speed on how to accomplish those requirements.  Incentive to accomplish 
difficult requirements also drops if there isn't an explanation of why they're 
required, and several people are questioning why packing old version of wine 
are needed.  [I don't personally understand what "for QA reasons" means.]

> Given the nature of Git, others are not blocked from working on the
> packaging. (Although I surely won't deny that coordination among all the
> other non-maintainers would be easier if they had access to the official
> VCS, especially if the people who do have access to it are not active.)

Er... sort of.  Work in Git that is never pulled into the main repo is 
effectively a separate effort.  Based on Ove's time overload I doubt that he 
has time to pull, review, and merge git branches, and then give feedback on 
someone else's work.  :-/

> Also, let's keep in mind that VCS commit access in Debian is not a
> requirement to modify a package. Our main "VCS" is the Debian archive
> and all (uploading) Debian Developers have access to it.
> So nobody is "stuck". But if packaging work continue to happens outside
> the official VCS and will keep on having troubles being merged into it,
> at some point people will probably feel the need to NMU the packages ---
> better if with sensible delays that allow for review by others. It would
> be preferable to reach a consensual solution before that. But the option
> is on the table, as it is for every other package in the archive.

For simplicity, let me try to cut-to-the-chase.

Michael Gilbert has made wine packages for 1.1.39, 1.1.40, 1.1.41, 1.1.42.  
They may or many not meet Ove's requirements.  What do you recommend he do 
with them?

I suspect the only viable answer is "wait for Ove to review them" -- and if 
that's the case, then he's effectively "stuck" for the time being, because it 
probably doesn't pay to continue to package further versions without knowing 
if the packages he's creating meet the requirements.  Normally this "stuck" 
period wouldn't be a problem, except that Debian is heading towards a freeze 
for the release of Wheezy, so there's some time pressure.  The wine packaging 
is apprently complicated, and Ove described the time required to be weeks of 
effort at minium for someone motivated, and likely to be longer.  I believe 
that timeframe makes the assumption that the work is correct, i.e. meets the 
QA/multiarch/backportability requirements.

My personal conclusion to all this is simply "something's gotta give".

  -- Chris

Chris Knadle
GPG Key: 4096R/0x1E759A726A9FDD74

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: