On Wed, 6 May 2015 20:36:25 +0200 Samuel Thibault <sthibault@debian.org> wrote: > Neil Williams, le Wed 06 May 2015 12:03:30 +0100, a écrit : > > If the patch *is* trivial and testable then it is up to the porters > > to arrange a fully tested NMU. > > How can a porter fully test a package? Only maintainers really know > their package well, testing a package is rarely documented. Anyone submitting a patch needs to at least be able to show that the patch works and does not cause further bugs in the package. That means at least testing the package - that's nothing to do with porting, it's general bug handling. ci.debian.net is one way that the problem of testing a package is improving. I did qualify the statement you've quoted to specify that the package is testable. > > Maintainers should help porters for release architectures wherever > > possible - for non-release architectures, that really isn't > > something you can do anything about except do the work yourselves. > > So you mean Debian does not welcome ports? Non-release architectures and toy ports require a lot of work by those who want that functionality but that does not mean that those desires can be transferred onto others. Debian does welcome ports but the workload resides with those who want the port in Debian. The presence of the port must be justified by the work that people are willing to contribute to it. With a port which is keeping up with developments across the distribution, that is easier and more people join the work. Ports that have a clear, attainable, goal of becoming a release architecture in the next cycle and remaining so for years to come are easier to join and the port itself gains acceptance more easily than non-release architectures. That is how ports like arm64 got into Debian - by a lot of people doing a lot of work themselves on the basis that those people wanted arm64 in Debian. (I can't speak of the pp64el port, I wasn't directly involved in that but I'd be surprised if it was substantially different.) Ports like that can continue to move forward - at speed - even when there is a complete lack of physical hardware, purely due to how the work can be spread over enough people. If the number of people falls below a critical level, that work becomes prohibitive but that does not mean that Debian has to suddenly take over the work. Debian cannot do that. > (I'm sorry, but "just do all the work" is not welcoming, to me) That is a big warning sign right there. Where is the team? Where are the other people driving this? Is it really just you? You can continue expecting others to do the work for you (which leads to bugs sliding down the priority list of some of the maintainers) or you can do the work. Unless more people join in the effort, that is clearly not going to be sustainable and I do think this needs to be acknowledged. Any project can get to a point where further work is counter-productive. The maintainers are not ignoring bugs to spite you, they have other priorities which are more fun and more interesting. Unless the objective becomes more appealing to a wider range of people, bugs will continue to slide down the priority list - there are simply not enough people who care enough about the work. If those people have not been persuaded already, it is unlikely that things will change substantially any time soon. I've stepped away from a few projects over time due to issues like these. I've moved on to other, active, projects which are able to keep up with changes across the distribution and I have been and continue to be massively happier by doing so. When there are not enough interested people that the task becomes "just do all the work yourself" then the question is unavoidable - has the time come to quit and do something else? It's no fun working into a dead end - the wise thing to do is to change course before it gets that far. I've been in situations where everything comes down to me and if I didn't get problem X fixed then nobody else would (or in some cases, could). That isn't healthy for the project and it wasn't healthy for me. The workload actively blocks adding more people to the team because there isn't time to get others up to speed. The answer to that is not to continue fighting but to step back and find something else to do. I had many, many people thanking me for the work I'd done, I didn't get as many woeful tales as I was expecting (hardly any, really) because those who cared about the work also knew how much work it was requiring just to stand still. (I even had some of the people who thanked me stepping in to defend my decision to cease work on the project to those who were spreading their tales of woe.) This is why I stopped work on Emdebian Crush all that time ago (after Lenny). It's why stepping back from Emdebian Grip last year was absolutely the right thing to do as well - before that got into the acute problems which affected Crush. There are warning signs in these things and the feeling that you have to "just do all the work" is a big RED FLASHING STOP sign. Been there, done that. Please don't follow. I don't care who you are, I wouldn't wish that on anyone. There's always another project around the corner which will be a lot more fun, that's the thing with free software. This will be my last message in this thread. I've said what I wanted to say, it's up to others to determine their own responses. I've tried to be as general and helpful as I can and now it's time for me to get back to fun stuff. Make of it what you will. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpOebg2G85Ar.pgp
Description: OpenPGP digital signature