Hi Maxy,
On Thursday 07 August 2014 12:44:37 Maximiliano Curia wrote:
> ¡Hola Philip!
>
> El 2014-08-07 a las 10:39 +0200, Philip Muskovac escribió:
> > Wasn't the whole point of the maintainer change that debian maintainers were
> > grumpy about getting mails from issues in derivatives?
>
> Afaik it was for reports reported to the Debian maintainers that were unaware
> or not interested in the derivatives, if we are merging the teams then that
> complain shouldn't apply, it sort of depends on the noise level it generates,
> though.
>
> Is there a way to configure the launchpad bugs to be sent to another ml
> instead
> of the Maintainer address ?
Launchpad doesn't really care about the Maintainer that much. At least it
doesn't matter for the default bug mails so that's a non-issue. I think it's
more about people that know a bit about the package management seeing the email
address in the package manager.
>
> > We do that really to make our life easier... and did you dump kde-sc-dev-
> > latest?
>
> No, but I haven't updated it in a while. It might be obsoleted after kf5, I
> don't know.
>
> > What we do is pretty much a replacement for that as versioned breaks
> > don't work on launchpad.
>
> They get ignored? We still need them for moving files between packages
> and such.
They don't get ignored, but if one build-dep breaks another the build will just
FTBFS instead of dep-wait on the new version. And even scripted retrying of
hundreds of builds is not really fun so we dumped kde-sc-dev-latest.
The reason why we still bump versions all the time is to automatically catch
kde-internal lib transitions. So even if we only update the changed packages
this should still depend on the most recent packaged version (which should at
that point be scripted)
On that point, how do you plan to handle no-change updates for kf5? As far as I
remember upstream did say that having mismatched versions between kf5
components is unsupported.
>
> > How would you propose we handle updating copyright files? As you probably
> > know
> > we are pretty lazy when it comes to that (as it's a horrible black hole for
> > developer time). Would you be fine with updating that whenever you get to
> > the
> > point of uploading? Or do you have a process that allows updating them
> > pretty
> > fast?
>
> Doing a git diff upstream/old_version upstream/new_version | grep -i copyright
> helps, specially with no changes, but after a while you need to review the
> whole copyright file again.
>
> There are a few projects to improve the copyright file checks [1] and
> generation [2], but nothing great. In particular, I don't like the generation
> tools that drop any change manually made to the copyright file. I use a dumb
> wrapper around licensecheck [3] to group the result by license and some vim
> macros to reformat it.
>
> > Maybe we could set up a script to check the copyright changes between
> > upstream
> > versions to make that faster?
>
> Not an easy task, but it may be possible to do a tool that either parses the
> git diff or that calls licensecheck in the old and the new tree and parses the
> licensecheck diff.
>
> [1]: https://github.com/agustinhenze/dlt
> [2]: https://code.launchpad.net/~clint-fewbar/+junk/lcheck
> [3]: http://maxy.com.ar/debian/license-helper.py
>
[3] is already more helpful than the other scripts I ran into so far so thanks
for sharing that.
Going back to the original mail and the branch layout my original approach
might've been a bit over complicated for what we actually need...
So assuming a package that can be synced, where would we put the updates?
'master' seems to be meant for anything that targets unstable, so if you want
to target 4.13 for the time being, should our changes for 4.14 be put into a
'next' that merges the unstable changes from master and is later merged back
into master?
Packages with a permanent diff from us lead back to my original proposal, which
would mean 'master', 'next' like above and e.g. 'utopic' that we would
continuously merge with next.
Does that sound sane or do you have a better idea?
Philip
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
