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

Re: On mass renames

On Thu, 18 Dec 2008 20:40:23 +0100
Nicolas Mailhot <nicolas mailhot laposte net> wrote:

> Sometimes, it is necessary to perform a mass rename to bring some
> consistency to a class of packages.

Yeah, after a guideline change or a mass change upstream. ;( 

> In that case any workflow that proceeds package by package is the road
> to failure, since
> — either each package is done separately by different people with
> little coordination (and you don't get consistency, some packagers
> will always slack or fail)

But if it's done based on a guideline or upstream change, shouldn't
they all be consistent with the new guideline or upstream name?

> – or one person goes through each package and you get burnout and
> again, failure (and I won't even speak of doing a new review for each
> package)

Yeah, also one person looking at a bunch of packages in a row could
easily miss something from looking at too many things at once. 

> I'd like to see a mode where:
> — a list of consistent renames is approved collectively
> — the associated cvs work is done in one shot by infra
> — each individual packager gets to work on the spec changes of his
> packages
> — an experienced packager or a group of packagers is mandated to check
> it's done correctly and eventually to substitute to the packagers who
> don't do their bit at all

I'm not sure what this saves over the proposed 'post to the list and
get one packager to check your spec/renamed package' ?
Using that maintainers could update, post to the list, and the
packager/group of packagers could approve them. 

I suppose it might be quicker if timing is important. 

Would you be able to propose an amendment to 
that would cover this case in a way you think is good? 

In general renaming a package isn't that hard, it's just that some
people don't pay attention to the details on Obsoletes/Provides, which
causes a mess. I would like to get someone to review those changes so
this is caught before the package is built/pushed. Thats all. 


Attachment: signature.asc
Description: PGP signature

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