RFC: Last rites for $package ...

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Last rites for $package ...

Enrico Weigelt, metux IT service

Hi folks,


maybe you remember the discussion about package removal and
problems for users on that ...

The problem was: someone (who's not reading this list) might be
interested in some package (or even had installed it) and now
gets trouble because its (from his view) sudden removal.

An solution could be an database of packages scheduled for
removal. But this database has to be maintained. And it doesn't
seem that there's someone who's interested in doing this extra work.

As I've seen talks about such removals seem to happen under the
suject "Last rites for $package", I'm now going to set up an little
mail robot, which catches those mails and adds the named package
to an removal-scheduled-database.

To make this working realiably, we simply need to agree on
one thing:

: If an package is going to be removed, there *always* has to be
: an discussion w/ subject "Last rites for $package"
: (where $package is the qualified package / port name)

Maybe we could also define other some other subject for the
cases that removal is aborted or committed.


What do you think about that ?


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
  http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
        http://patches.metux.de/
---------------------------------------------------------------------
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Last rites for $package ...

Joshua Jackson-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enrico Weigelt wrote:
> Hi folks,
> <snip>
To be perfectly honest, we're not going to hold someone's hand with
this. We shouldn't be expected to. A package will be in mask for a
month before its removed. That's a good warning sign that something is
up. You can view the package mask file and see the reason behind it,
as well you have this mailing list where announcements about what is
masked and when its removed. If people can't find the reason from all
those sources of data..then quite frankly..there's a larger issue
going on with them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFHDUySENan+PfizARAk/eAJ4jHTvqjjWBHFSgY24Wkb3XTits3QCfVgUz
JOj/wWgWBaCVxVyfeh23PKM=
=1IPj
-----END PGP SIGNATURE-----

--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Last rites for $package ...

Mike Kelly-4
In reply to this post by Enrico Weigelt, metux IT service
On Thu, 28 Sep 2006 22:28:27 +0200
Enrico Weigelt <[hidden email]> wrote:

> An solution could be an database of packages scheduled for
> removal. But this database has to be maintained. And it doesn't
> seem that there's someone who's interested in doing this extra work.

As I understand it, every one of these package removals is first
package.masked for 30 days before the ebuilds are actually removed.
So, the user has a month in which to do something about this. When they
sync and try to update any time during that month, they will see a
message, telling them that that package is scheduled for removal, and
pointing them at the relevant bugs in bugzilla.

So, isn't package.mask already that "database"? Or am I missing
something?

--
Mike Kelly
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Last rites for $package ...

Steve Dibb
In reply to this post by Enrico Weigelt, metux IT service
Enrico Weigelt wrote:
> An solution could be an database of packages scheduled for
> removal. But this database has to be maintained. And it doesn't
> seem that there's someone who's interested in doing this extra work.
>  

Well, there is bugzilla.  Just track any bugs with [hidden email] in
there and you'll see what were up to.

Steve
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Last rites for $package ...

Alec Warner-2
In reply to this post by Enrico Weigelt, metux IT service
>
> The problem was: someone (who's not reading this list) might be
> interested in some package (or even had installed it) and now
> gets trouble because its (from his view) sudden removal.

My project is responsible for what I'd imagine to be the most tree
removals; we have strict guidelines regarding packages.  For instance;
the package must have a bug filed against it; it gets masked for 30 days
prior to being actually punted; you should always see e-mail on this
list regarding both it's masking and removal...These are all things to
ensure people are aware of what is going on; this is not some "hidden"
process.

>
> An solution could be an database of packages scheduled for
> removal. But this database has to be maintained. And it doesn't
> seem that there's someone who's interested in doing this extra work.

Or you haven't talked to me or Beandog at all; since he has been working
on this a while (now with upgraded tools!).  There has been a GPNL
description on the Treecleaner project page since day one; since *I*
wrote it.  Yeah it's not up yet; yeah I'm removing packages anyway;
hopefully with the GPNL it will be more obvious to some people; but then
you still need to search GPNL to see what the heck is scheduled for
removal.  Frankly if you can't read the ML archives or search on bugs
when a package you find is masked; then I don't really know where else
to point you...

-Alec Warner
TreeCleaners Lead
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Last rites for $package ...

Thilo Bangert-3
> Or you haven't talked to me or Beandog at all; since he has been
> working on this a while (now with upgraded tools!).  

what i'd like to see is a system, to which one would give a package name,
which then handles the removal (almost) automatically.

that way devs would have an easier time actually removing some cruft and
you guys would be freed from typing the same stuff over and over.
this system could be responsible for sending the out last rites mails,
masking the packages in package.mask etc... enrico would get his database
for free, both listing those that are pending removal as well as a
history of removals including the reason plus a pointer to the
corresponding bug...

don't know if that is what you are aiming at, but currently the process of
removing a package is a true chore and i admire your dedication to it. (a
big THANKS btw)

regards
bangert


attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Last rites for $package ...

Steven J. Long
>> Or you haven't talked to me or Beandog at all; since he has been
>> working on this a while (now with upgraded tools!).
>
> what i'd like to see is a system, to which one would give a package name,
> which then handles the removal (almost) automatically.
>
> that way devs would have an easier time actually removing some cruft and
> you guys would be freed from typing the same stuff over and over.
> this system could be responsible for sending the out last rites mails,
> masking the packages in package.mask etc... enrico would get his database
> for free, both listing those that are pending removal as well as a
> history of removals including the reason plus a pointer to the
> corresponding bug...
>
This sounds like an excellent idea. Do the `upgraded tools' already automate
this process?

After all, that's what computers are good at- automating workflow.

> don't know if that is what you are aiming at, but currently the process of
> removing a package is a true chore and i admire your dedication to it. (a
> big THANKS btw)
>
++


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: Last rites for $package ...

Alec Warner-2
Steve Long wrote:

>>> Or you haven't talked to me or Beandog at all; since he has been
>>> working on this a while (now with upgraded tools!).
>> what i'd like to see is a system, to which one would give a package name,
>> which then handles the removal (almost) automatically.
>>
>> that way devs would have an easier time actually removing some cruft and
>> you guys would be freed from typing the same stuff over and over.
>> this system could be responsible for sending the out last rites mails,
>> masking the packages in package.mask etc... enrico would get his database
>> for free, both listing those that are pending removal as well as a
>> history of removals including the reason plus a pointer to the
>> corresponding bug...
>>
> This sounds like an excellent idea. Do the `upgraded tools' already automate
> this process?

The 'upgraded tools' was in regards to the GPNL project; since Beandog
was using portageq to import metadata into the database; this turned out
to be a bad idea (slow as all hell).  The upgraded portion was Marien
writing some funky pkgcore voodoo to do the metadata import in about
three minutes.

Phreak and I have some scripts that automate portions of the removal
process (including adding stuff into the treecleaner overlay!) but I
know I'm not using em (not what I would call production ready yet).

I don't like automated E-mails all that much, tbh.  Right now my script
just generates the text for the e-mail and I read it over and add
comments and then paste it into my client ;)  Some people stated that
they liked more comments than just "masked for bug #XXXXXX' so I try to
provide those; a tool just won't cover it in that aera.

Also there is no history of removals other than the ebuilds go into the
treecleaner project overlay; which I guess provides a revision history
for removals by default (cool!).
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: Last rites for $package ...

Steven J. Long
Alec Warner wrote:

> Steve Long wrote:
>> This sounds like an excellent idea. Do the `upgraded tools' already
>> automate this process?
>
> The 'upgraded tools' was in regards to the GPNL project; since Beandog
> was using portageq to import metadata into the database; this turned out
> to be a bad idea (slow as all hell).  The upgraded portion was Marien
> writing some funky pkgcore voodoo to do the metadata import in about
> three minutes.
>
pkgcore does seem to have a lot going for it.

> Phreak and I have some scripts that automate portions of the removal
> process (including adding stuff into the treecleaner overlay!) but I
> know I'm not using em (not what I would call production ready yet).
>
> I don't like automated E-mails all that much, tbh.  Right now my script
> just generates the text for the e-mail and I read it over and add
> comments and then paste it into my client ;)  Some people stated that
> they liked more comments than just "masked for bug #XXXXXX' so I try to
> provide those; a tool just won't cover it in that aera.
>
Agreed, but isn't your time quite valuable? I understand that people /like/
more comments, but where is the actual *need* for that?

Part of the process (from what I've read) is decision making based on how
long it's been since a pkg was last updated in the tree, and how long it's
had outstanding bugs. (As well as upstream issues etc.)

If you had that info in an email as part of an automated process (which your
crew would still have to actually approve, and you can still add a couple
of lines about the maintainer or whatever) then the reasons would be clear.
And let's face it, anyone who's bothered is still going to get the same
level of warning. If they want to follow it up, then you can get into a
discussion.

> Also there is no history of removals other than the ebuilds go into the
> treecleaner project overlay; which I guess provides a revision history
> for removals by default (cool!).
>
Yes indeedy. Computers make things _easier_!

My £2 worth ;)


--
[hidden email] mailing list