[Pkg-samba-maint] wheezy bugs

[Andrew Bartlett]

On Tue, 2017-07-18 at 22:15 +0200, Mathieu Parent wrote:
> 2017-07-17 22:02 GMT+02:00 Andrew Bartlett <abartlet at samba.org>:
> > On Mon, 2017-07-17 at 16:04 +0200, Mathieu Parent wrote:
> > > )Hi Andrew,
> > > 
> > > 2017-07-17 9:01 GMT+02:00 Andrew Bartlett <abartlet at samba.org>:
> > > > I would really like to close out bugs in Samba 3.6 in our bugtracker.
> > > > They are never going to be fixed and this is now and for a year already
> > > > as I understand it under the control of the Debian LTS team for
> > > > security updates.
> > > > 
> > > > Can we close them now?
> > > 
> > > I'm ok with this (I think that the closed state is relevant to sid),
> > > but others don't agree.
> > 
> > OK.  If they want to speak up I'm happy to take guidance, but with over
> > 200 bugs, my feeling is that anything else is just going to make being
> > a new maintainer around here too over-whelming.
> 
> Yes. Let's close them (the version-tracking will show them once
> #868672 is fixed).

Good.

> > Is there some formal guidance somewhere?
> 
> I've found: https://wiki.debian.org/HowtoUseBTS which explain in
> detail version-tracking.
> 
> > I really don't like the false hope Debian bugs give, and actually wish
> > we had a way to auto-restrict them to issues in sid/testing
> 
> I agree that the closed state should refer to sid, and I think we
> should keep track of other bugs with version tracking and appropriate
> severity (i.e only take care of RC bugs).
> 
> > and issues in the packaging,
> 
> We also need to know which bugs hit our users. The tags upstream and
> fixed-upstream are very useful here. And the forwarded meta will
> automatically keep those updated.
> 
> > because as somebody has to say anyway, anything else
> > must go though upstream by our team policy, and almost certainly won't
> > be backported anyway.
> 
> If the rule is "upstream first", we break it from time to time
> (recently #739768).

That didn't break "upstream first", by my reading.  I don't mind Debian
having patches that are signed off by an upstream developer, ideally
after they are committed to Samba master. 

What I don't want is debian-only patches (like the old fhs.patch)

> If the rule is "sid first", I don't see any reason to break it.
> 
> > 
> > The (silly, IMNSHO) bar we/Debian have on stable updates makes this
> > particularly pointless.
> 
> The stable release team has always accepted when we wanted to upload
> the last point-release in the same branch. I want to do this ( for
> stretch but I need time (I'm already too late for 4.5.12 in 9.1). The
> LTS team is also less conservative.

OK.  That would be really good. 

> > > > Or if not, can someone tag them in a way that I can work on the
> > > > actually open bugs?
> > > 
> > > You can see bugs affecting sid via:
> > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;repeatmerged=on;src=samba
> > > 
> > > But I'm not sure that all bugs are properly versioned.
> > 
> > Almost none of them are, from what I can see.
> 
> OK. At least we should check the RC ones.

Thanks.  I do appreciate your continued work here.  I step in from time
to time, but you have kept this show on the road very well.

Hopefully we can find some more resources soon, and in the meantime if
we can make the job a little more documented and less burdensome then I
think that will help.

A clear guide on how to import, build and release a new Samba version
or security patch would help a lot.  I keep having to remember how gbp
works, and the process of adding a patch still feels like black magic. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba