Re: Intent to hijack Bacula
José Luis Tallón <jltallon@adv-solutions.net> writes:
>
> Hijacking a package without contacting the maintainer first is against
> the Developers' Reference and can only be considered a personal attack.
>
>
> I still don't know what is John Goerzen trying to achieve with this.
> More on this later.
This thread is refreshening in couple of points, because it opened
up discussion that may have become (or already is) a problem:
1. somebody starts nurturing a package
2. He's eager at start, but the steam doesn't last long
..
3. package slowly drops under lower and lower of pile of works
* taking care of things is starting to take too much time
* lacked experience in the first place?
4. The package starts being "unmaintained"[1]. Bug reports gow and
grow and nothing happens in year.
Just look at some packages, where bug reports have last been addressed
several years ago. Not good at all.
Then, a miracle happens
Person with competence comes, pulls up his sleeves and
puts the package in shape.
Voila, the package is maintained again.
Now, the orignal packager is not pleased at all. because
IT'S MY PACKAGE. IT BELONGS TO ME.
-- Lord of the rigs echoing...
ALTERNATIVE STRATEGY - BEING DYNAMIC
The developer manual could say something about non-active packages and
suggest clear procedures. Or the quality team should seek more closely
for MIA maintainers, who have bugs hanging in their packages that date
years back.
Unmaintained packages are not a healthy situation. The maintenance
process should encourage:
hijacking[2]
The current process unfortunately encourages keeping the status quo,
to not do "hijacks". The problem is that status quo doesn't promote
change; it discourages being dynamic, being active, taking active
role.
In contract being active and taking maintainership:
Get work done! Good!
=> Will serve the end users of package
=> Will satisfy all the 3rd party people that *care* to submit
bug reports in the hope that things will evolve
=> Will possibly activate the orig. maintainer of package from sleep
A sleeping maintainer is a bad thing. It woudl be good if the the
process alleviated that packages are not "personal artefacts", but
shared properties.
The end result is the only important one. To my understanding, the
goal is "to provide common good" -- that is: to provide service to end
users.
Jari
[1] Seasoned maintainers know the right thing: Orphan. Some
unfortunately cling on victory marks, and don't want to let go.
[2] Hijacking is not the same as lasking manner. There could be
clearly laid out rules for grace periods and time limits for original
maintainer to show the will to become active again. Otherwise the
package would be "up for grabs" with no further discussion needed.
In some way the "hijacking" is already encourages in small scale by
the NMU process. But in those cases the person fixing things usually
does not want to become new maintaineg; he only wanted to get fixes
in.
Reply to: