Re: Debian Archive architecture removals
On Wed, May 06, 2015 at 11:39:29AM +0100, Neil Williams wrote: On Wed, 6 May 2015 18:18:34 +0800 Paul Wise p...@debian.org wrote: On Wed, May 6, 2015 at 6:11 PM, Neil Williams wrote: You've admitted that the port cannot keep pace because it needs changes to be made by maintainers who do not see the port as a particular priority and that this blocks or impedes further changes. You've tried and failed to increase the level of interest in the port which would have changed those priorities and the port has failed to gain more manpower. That is a failed port. Sounds like you're saying hurd-i386 has failed because of lazy maintainers? I have certainly merged Hurd and kFreeBSD patches that were submitted and even written patches when they were needed even if I am not currently running these ports. Other maintainers are likely to have done the same too. However, *not enough* maintainers have considered similar patches to be of sufficient priority for their workload - because the port has failed to gain sufficient interest. It's hard to gain sufficient interest if doing so requires you to have sufficient interest first. You need a number of patches to be applied for your port to gain a critical level of usefulness. Maintainers ignore your patches because it's a minority port anyway. But *because* they ignore your patches, your port will never leave the minority label. That's a vicious cycle; you can't get useful until things improve, and you can't improve until you get useful. This is why unreleased can be really useful, as it allows people to break out of the vicious cycle and get things to a working state. Having said that, I think it *should* be important for maintainers to consider not ignoring other people's work as an important part of their workload. Yes, our constitution says it does not (...) impose an obligation on anyone to do work for the Project. However, it immediately goes on to *also* say that you (...) must not actively work against these rules and decisions properly made under them. I've always interpreted that particular requirement as you should not stand in the way of people doing work if you're not willing or able to do it yourself, and I don't think that's too far-fetched. I mean, sure, nobody's asking anyone to write a porter patch. However, if such a patch is written by someone else, I think it *should* be your requirement as a maintainer to either do an upload which includes it, or explain why you won't do that (e.g., because the patch introduces a bug of some sort). I'd even go a step further, and would like to suggest that we should treat bug severity important, tagged patch as RC, especially if it's also tagged to be RC for a non-release architecture. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Debian Archive architecture removals
On Wed, 6 May 2015 10:11:02 +0200 Samuel Thibault sthiba...@debian.org wrote: Neil Williams, le Wed 06 May 2015 08:56:38 +0100, a écrit : Ports which take so long to develop that a stable release is deemed unlikely will also struggle. That is a problem caused by that port, not by the project or other maintainers. Not only. A typical scenario that does happen and can really hinder porting is when an upstream source often introduces non-portable changes. The package needs to be ported, the porter team thus provides a patch. The patch lingers in the BTS until the maintainer makes a new upload for a new upstream release. He integrates the proposed patch, but the new upstream release introduces another non-portability issue, and thus another patch is needed. The porter team provides a patch, which lingers in the BTS until etc. In the end the package never gets to build on the port. That is still a problem of that port - when working with volunteers, if proponents of the port cannot engender enough enthusiasm for that particular itch then you will struggle to get other people to do work which only benefits that itch. You cannot blame the maintainers for finding something more interesting upon which to spend their limited and valuable volunteer time - in Debian or upstream. The problem - and the fix - lie within the realms of that port, not the project. Something which is important to a small number of people does not put any obligation on the rest of the project - it is a toy, a sideline, a curiosity or a diversion, depending on viewpoint. The project has teams and methods to agree on what is important to the project and it has methods to ensure that those priorities have costs if maintainers ignore those priorities. Like it or not, work which does not actually benefit any of those established priorities will *not* get priority and will likely languish in the vague hope that some day there might be enough spare time to get everything else done which is of higher priority. Portable vs non-portable changes is itself a project decision - code is considered portable if it builds successfully on all release architectures. Code in Debian doesn't need to be portable to non-release architectures. It's nice if it can be done and it is done if the maintainer/upstream has an interest but it is not and cannot be required or expected. Projects can choose to support Amiga or RiscOS or BeOS or OS/2 or CP/M or Ming or Android if they want - doesn't mean that changes in other packages which do not support those are non-portable. Portability is a movable feast and in Debian, it relates to release architectures. If a particular port wants that kind of support, it needs to enthuse enough people to make it relevant to the masses. Lack of widespread interest in any particular port is a problem with that port not having widespread appeal. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp_w5XaE4C9b.pgp Description: OpenPGP digital signature
Re: Debian Archive architecture removals
Neil Williams, le Wed 06 May 2015 09:47:36 +0100, a écrit : Lack of widespread interest in any particular port is a problem with that port not having widespread appeal. And lack of helping maintainers will entail a lack of working stuff in the port, and thus a more difficult appeal, and the loop is over. I agree that maintainers shouldn't be obliged to debug stuff, include unclear patches etc. But we do see now and then obvious patches which don't get included. So the porters did spend time to make the port support more packages (which is necessary to get to master and thus win the FCC label), and thus have less time to work on the port itself and make the port appealing, and only to see their patches being ignored. Really, I do agree with you to some extent. But the reality is that quite a few BTS entries get much beyond that extent. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506093545.gb3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
On Wed, May 6, 2015 at 6:11 PM, Neil Williams wrote: You've admitted that the port cannot keep pace because it needs changes to be made by maintainers who do not see the port as a particular priority and that this blocks or impedes further changes. You've tried and failed to increase the level of interest in the port which would have changed those priorities and the port has failed to gain more manpower. That is a failed port. Sounds like you're saying hurd-i386 has failed because of lazy maintainers? I have certainly merged Hurd and kFreeBSD patches that were submitted and even written patches when they were needed even if I am not currently running these ports. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HJaqf+=ttqlorkt8r3k8a4yjudwrdipg_1xkub+pn...@mail.gmail.com
Re: Debian Archive architecture removals
On Wed, 6 May 2015 11:35:45 +0200 Samuel Thibault sthiba...@debian.org wrote: Neil Williams, le Wed 06 May 2015 09:47:36 +0100, a écrit : Lack of widespread interest in any particular port is a problem with that port not having widespread appeal. And lack of helping maintainers will entail a lack of working stuff in the port, and thus a more difficult appeal, and the loop is over. Only because there aren't enough people sufficiently interested because what you are lacking is manpower to keep up. A port which cannot keep up with itself is just a nice idea that didn't actually work and that will reduce any remaining appeal the port once had. So, yes. The loop is over. It sounds like it is time to accept that. But we do see now and then obvious patches which don't get included. So the porters did spend time to make the port support more packages (which is necessary to get to master and thus win the FCC label), and thus have less time to work on the port itself and make the port appealing, and only to see their patches being ignored. Really, I do agree with you to some extent. But the reality is that quite a few BTS entries get much beyond that extent. You are again viewing the priority only from your own viewpoint. The entries in the BTS which you describe have clearly not got beyond the extent of the priority of the maintainer - the maintainer has other stuff which is - by definition - higher priority and more fun. Just because you view these entries as waiting too long for your needs does not mean that the maintainer needs to do anything about it. The maintainer, like it seems a lot of other people, doesn't have sufficient interest to make that work a priority. The only thing you can do to change that is to make the port more relevant, interesting and active. If the only people interested are all at 100% then the port has failed to gain enough interest. A port in this state has failed to attract enough manpower to keep itself alive - where alive is the point where required changes can be made in a suitable timeframe to not overlap with the next round of changes, allowing the port to move forward. A port which stagnates at the point of not being able to retain an amount of working packages and there is too much work to do to get new packages supported is a port which has *failed*. It has failed to attract enough interest, to have a wide enough appeal and to have enough manpower to survive. It's dead Jim. You've admitted that the port cannot keep pace because it needs changes to be made by maintainers who do not see the port as a particular priority and that this blocks or impedes further changes. You've tried and failed to increase the level of interest in the port which would have changed those priorities and the port has failed to gain more manpower. That is a failed port. Stop wasting your (and my) time. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpcE0Od7wgpA.pgp Description: OpenPGP digital signature
Re: Debian Archive architecture removals
On Tue, 05 May 2015 23:36:32 +0100 peter green plugw...@p10link.net wrote: Perhaps we need a political decision here? When considering maintainers not directly involved in the port, motivation for doing work which only helps a particular port tends to be easier to find when the objective of that port is to either get into a stable release or to scratch their own itch. Therefore, ports like arm64 and pp64el had the best of the input because there were a large number of active people actively working on the port, a lot of people generally interested in the port and a high probability that the port would make the next stable release, jessie. Ports which were in release state but which have lost support will struggle. Ports which take so long to develop that a stable release is deemed unlikely will also struggle. That is a problem caused by that port, not by the project or other maintainers. Proponents of such ports cannot blame others for the failure of their favourite port to attract interest. In some ways, ports which are not on track for a stable release are the second-class ports. arm64 and pp64el were not much of a problem in terms of getting fixes uploaded. That's not to say either arm64 or pp64el was trivial - a lot of people put in a lot of work - but neither was ever in serious doubt either. What should the expectations of maintainers of second class ports be? Essentially (and hopefully not stating the obvious too much): 0: That maintainers not involved in the port will struggle to find the motivation to work on changes which do not benefit a stable release or their own self-interest. 1: That volunteers will find something else to do if there is a (relative) lack of motivation for a particular piece of work. 2: That the focus of most maintainers is split between their own itches and the next stable release. Work which doesn't help either of those is going to be lower priority. 3: Nagging maintainers who lack motivation for a particular piece of work is generally counter-productive. (This includes but is not limited to severity ping-pong.) 4: NMUs have to be done with care - especially if the change is solely for the second-class port. It's much easier to get changes in which will help other ports or general code quality on all ports (like dh-autoreconf et al.) Under no circumstances can a porter NMU cause a regression on a more actively supported port - and it would be the porter who would end up checking that. 4: Ports which are not going to be considered for release are, by definition, toy ports and cannot expect the same support as release ports. Decisions made regarding a release port do not create a precedent for, or necessarily have any applicability for, non-release ports. 5: All non-release architecture ports are unofficial and the decision on release architectures is down to the release team. How does that sound? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpdLMFoVYLox.pgp Description: OpenPGP digital signature
Re: Debian Archive architecture removals
Neil Williams, le Wed 06 May 2015 08:56:38 +0100, a écrit : Ports which take so long to develop that a stable release is deemed unlikely will also struggle. That is a problem caused by that port, not by the project or other maintainers. Not only. A typical scenario that does happen and can really hinder porting is when an upstream source often introduces non-portable changes. The package needs to be ported, the porter team thus provides a patch. The patch lingers in the BTS until the maintainer makes a new upload for a new upstream release. He integrates the proposed patch, but the new upstream release introduces another non-portability issue, and thus another patch is needed. The porter team provides a patch, which lingers in the BTS until etc. In the end the package never gets to build on the port. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506081102.ga3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
On Wed, 6 May 2015 12:49:44 +0200 Samuel Thibault sthiba...@debian.org wrote: Neil Williams, le Wed 06 May 2015 11:39:29 +0100, a écrit : It's not at all that the maintainers are lazy or that those maintainers could have done anything differently. Those maintainers have their workloads and have made an assessment of their priorities. I'm sorry I have to disagree here. When trivial patches get submitted, the extra load is negligible compared to general management of the package. You may consider a patch trivial, does not mean that the testing of that patch is trivial. If the maintainer does not consider such a change to be of a high enough priority, there is no reason to carry even a trivial patch amongst the many other patches and issues being handled by that maintainer. If the patch *is* trivial and testable then it is up to the porters to arrange a fully tested NMU. 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. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpbOx9grmRkn.pgp Description: OpenPGP digital signature
Re: Debian Archive architecture removals
Neil Williams, le Wed 06 May 2015 11:39:29 +0100, a écrit : It's not at all that the maintainers are lazy or that those maintainers could have done anything differently. Those maintainers have their workloads and have made an assessment of their priorities. I'm sorry I have to disagree here. When trivial patches get submitted, the extra load is negligible compared to general management of the package. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506104944.gd3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
On Wed, 6 May 2015 18:18:34 +0800 Paul Wise p...@debian.org wrote: On Wed, May 6, 2015 at 6:11 PM, Neil Williams wrote: You've admitted that the port cannot keep pace because it needs changes to be made by maintainers who do not see the port as a particular priority and that this blocks or impedes further changes. You've tried and failed to increase the level of interest in the port which would have changed those priorities and the port has failed to gain more manpower. That is a failed port. Sounds like you're saying hurd-i386 has failed because of lazy maintainers? I have certainly merged Hurd and kFreeBSD patches that were submitted and even written patches when they were needed even if I am not currently running these ports. Other maintainers are likely to have done the same too. However, *not enough* maintainers have considered similar patches to be of sufficient priority for their workload - because the port has failed to gain sufficient interest. It's not at all that the maintainers are lazy or that those maintainers could have done anything differently. Those maintainers have their workloads and have made an assessment of their priorities. If those changes ended up lower down that list of priorities than the porters can manage to support, then that would be the time for those interested in the port to do that work themselves, as a fully tested NMU. It is at this stage that the port could be considered to have failed if the port fails to attract enough people (maintainers or not) to do the work that the port requires. Then the port may regain some interest and some support if the work is done and that can change how maintainers assess the priority of the changes requested by the port. When it works, it is a snowball effect - however once the ball slows down, it can be very difficult to make progress and without progress, there is no point continuing. Working ports are at the crest of a wave - if the wave crashes down, it's easy to spot that it's failed. If the wave simply moves on, leaving the port behind, it is harder to accept, very hard to regain momentum and high time that the porters ask themselves the hard question of whether it is worthwhile to continue, as the crest of the wave rushes off ahead of them. We're all aware of how this works with applications and upstreams - it applies to ports too. Restarting upstream maintenance of a package is hard and often pointless - it can be exactly the same with ports which have stalled due to lack of manpower (itself due to lack of widespread interest). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp8FMjCgdwCS.pgp Description: OpenPGP digital signature
Re: Debian Archive architecture removals
On Wed, May 6, 2015 at 7:03 PM, Neil Williams wrote: 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. One could argue the same for the official ports other than amd64 too. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6e82evulhtqz_5wusjzq_zceo1c0lfuyrqbffbf9pg...@mail.gmail.com
Re: Debian Archive architecture removals
[ with my m68k buildd maintainer and (ex-?) porter hat ] Aurelien Jarno dixit: - debian-ports uses mini-dak instead of dak. It uses less resources and brings some features that are useful for new architectures like accepting binary uploads when it improves the version even if it is not the latest one or an unreleased suite for packages built from modified source (hence architecture specific). On the contrary its There’s two more bugs that *really* disturb porters’ work in it: • it is possible to do a binary upload of the *same* version of a pak‐ kage that is currently in the archive, which breaks the package until the next bigger upload fixes it: mini-dak serves the checksums from one of the uploads but the .deb files from the other of the uploads (this can happen in case of human errors, or caused by a w-b hiccup, when a package was taken by someone (porter or buildd) and is in Building state, then vanishes from the DB, then comes back) • (much worse) library transition old-version keeping is broken: suppose there is src:isl (= 0.12.2-2) building libisl10 in the archive and built on some architecture; then, someone uploads src:isl (= 0.14-2) which builds libisl13 instead; in dak (on the main archive), the old libisl10 binary packages are kept in the Packages.gz file until there is no dependency on it any more; mini-dak just throws all NBS binary packages away immediately Oh, and the performance. On the other hand, things like the existence of unreleased really *do* help, so, a ｂｉｇ thank-you to Aurélien for running d-ports❣ bye, //mirabilos PS: I’d be happy to discuss things (dpo experience) on debconf, if I manage to make some time for that in the days I’m there; can’t say beforehand, unfortunately -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1505061037260.27...@herc.mirbsd.org
Re: Debian Archive architecture removals
Neil Williams, le Wed 06 May 2015 11:39:29 +0100, a écrit : If the wave simply moves on, leaving the port behind, it is harder to accept, very hard to regain momentum and high time that the porters ask themselves the hard question of whether it is worthwhile to continue, as the crest of the wave rushes off ahead of them. Just answering this part, I won't bother commenting on the rest. I could be thought that you imply that the hurd-i386 port is in that stage. I want to insist that it steadily improves, it's not on the down slope. There *is* enough manpower to keep up its state, just not enough manpower to make it move as fast as other ports like arm64/ppc64. My concern is whether moving to d-p would slow this down by adding unnecessary workload on the porters. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506105505.ge3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
Neil Williams, le Wed 06 May 2015 20:34:15 +0100, a écrit : On Wed, 6 May 2015 20:36:25 +0200 Samuel Thibault sthiba...@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 - Sure. I thought you meant more than that with fully tested. (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? It's far from just me. If it was just me we would be very far from the current stage. -- Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506204731.gm3...@type.youpi.perso.aquilenet.fr
Re: Debian Archive architecture removals
On 2015-05-06 10:44, Thorsten Glaser wrote: [ with my m68k buildd maintainer and (ex-?) porter hat ] Aurelien Jarno dixit: - debian-ports uses mini-dak instead of dak. It uses less resources and brings some features that are useful for new architectures like accepting binary uploads when it improves the version even if it is not the latest one or an unreleased suite for packages built from modified source (hence architecture specific). On the contrary its There’s two more bugs that *really* disturb porters’ work in it: • it is possible to do a binary upload of the *same* version of a pak‐ kage that is currently in the archive, which breaks the package until the next bigger upload fixes it: mini-dak serves the checksums from one of the uploads but the .deb files from the other of the uploads (this can happen in case of human errors, or caused by a w-b hiccup, when a package was taken by someone (porter or buildd) and is in Building state, then vanishes from the DB, then comes back) • (much worse) library transition old-version keeping is broken: suppose there is src:isl (= 0.12.2-2) building libisl10 in the archive and built on some architecture; then, someone uploads src:isl (= 0.14-2) which builds libisl13 instead; in dak (on the main archive), the old libisl10 binary packages are kept in the Packages.gz file until there is no dependency on it any more; mini-dak just throws all NBS binary packages away immediately Then that's only one more, because it's exactly what I described in my mail. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Debian Archive architecture removals
On May 06 2015, Neil Williams codeh...@debian.org wrote: 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. It seems to me that you don't (want to?) realize that in some cases the porters are doing all the work they can technically do. If a tested patch languishes in the BTS, there is no one other than the maintainer to do the remainining work. You stated yourself in another mail that periodic pushing and pings are not helpful, and an NMU still needs to be integrated by the maintainer. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnhx8mot@thinkpad.rath.org
Re: Debian Archive architecture removals
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. 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? (I'm sorry, but just do all the work is not welcoming, to me) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506183625.gi3...@type.youpi.perso.aquilenet.fr
Re: Debian Archive architecture removals
On Wed, 6 May 2015 20:36:25 +0200 Samuel Thibault sthiba...@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
Re: Debian Archive architecture removals
On Tue, 05 May 2015 09:17:02 +0200, Samuel Thibault wrote: (replying only to -devel) * Appearing on packages' and maintainers' PTS pages like http://buildd.debian.org/bash and https://buildd.debian.org/sthiba...@debian.org This makes people aware of portability issues; when hurd-i386 moved there some years ago, that did make a change: we saw maintainers caring and fixing their packages, quite often the fixes are quite trivial. It would be useful to see other debian-ports results there for portability checking, notably hppa. There is already a link to buildd.debian-ports.org, but people do not even notice it, let alone think about checking it. Just one minor aspect from a non-porter maintainer: I don't care if the build logs are split betwwen buildd.d.o and buildd.debian-ports.org or merged on one page; but what I would like in any case is to have a clear indiciation which of the architectures are release architectures and which aren't. (Which is not the case currently, as buildd.d.o lists hurd*, kfreebsd*, sparc and gives no visual clue that they are different.) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Pink Floyd: Signs of Life signature.asc Description: Digital Signature
Re: Debian Archive architecture removals
On Tue, 2015-05-05 at 09:17 +0200, Samuel Thibault wrote: [Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? One of the main problems with debian-ports is that the Sources.gz file is empty: http://ftp.debian-ports.org/debian/dists/unreleased/main/source/ [DIR] Parent Directory Release16-Aug-2013 08:22 119 Sources.bz205-May-2015 06:22 28 Sources.gz 05-May-2015 06:220 The only allowed sources.gz file is e.g. for sid: http://ftp.se.debian.org/debian/dists/sid/main/source/Sources.gz As a work-around architecture-dependent sources have to be uploaded to the corresponding binary tree, e.g. http://ftp.debian-ports.org/debian/pool-hurd-i386/main/libg/libgnome-keyring/ *.deb files libgnome-keyring_3.12.0-1+hurd.1.debian.tar.xz22-Apr-2015 18:59 5.5K libgnome-keyring_3.12.0-1+hurd.1.dsc 22-Apr-2015 18:59 2.8K libgnome-keyring_3.12.0.orig.tar.xz 22-Apr-2015 18:58 425K and the source files can be obtained with dget /path/to/the/*.dsc The number of architecture-dependent packages is low, for Hurd currently 26, to be lowered significantly when some Upstream and Debian bugs have been resolved. Is there no straight-forward way to solve this problem? According to Samuel, it is due to Debian Archive Kit (dak) complexity. Can somebody explain why it is so difficult? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1430830855.4404.142.ca...@gmail.com
Re: Debian Archive architecture removals
Richard Braun, le Tue 05 May 2015 12:27:10 +, a écrit : On Tue, May 05, 2015 at 01:36:57PM +0200, Arne Babenhauserheide wrote: Given that the package coverage of the Hurd continuously increased and that it just released 0.6 of its core components[1] along with releasing Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off ftp-master. It's irrelevant. Yes, my point is that it should not be relevant. Being mirrored is clearly useless. The concern is actually that being on master is currently more than about just that. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505130015.gk6...@type.labri.fr
Re: Debian Archive architecture removals
Am Montag, 20. April 2015, 00:22:08 schrieb Joerg Jaspert: hurd-i386 = Well before wheezy was released, we talked with the HURD porters, and they agreed to re-check their archive status just after the wheezy release[1]. The plan was to move the HURD port off ftp-master if it wasn't included as a technology preview or full release arch. HURD wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. Given that the package coverage of the Hurd continuously increased and that it just released 0.6 of its core components[1] along with releasing Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off ftp-master. [1]: http://www.gnu.org/software/hurd/news/2015-04-10-releases.html [2]: http://www.gnu.org/software/hurd/news/2015-04-29-debian_gnu_hurd_2015.html http://thread.gmane.org/gmane.os.hurd.bugs/27177 The Hurd isn’t an old architecture which is slowly fading away but rather slowly but steadily progressing and getting more stable. The qemu live image works right away, including the translator tests which show the unique capabilities of the Hurd. Best wishes, Arne -- Ein Würfel System - einfach saubere Regeln: - http://1w6.org signature.asc Description: This is a digitally signed message part.
Re: Debian Archive architecture removals
Svante Signell, le Tue 05 May 2015 15:38:27 +0200, a écrit : On Tue, 2015-05-05 at 15:09 +0200, Samuel Thibault wrote: Svante Signell, le Tue 05 May 2015 15:00:55 +0200, a écrit : One of the main problems with debian-ports is that the Sources.gz file is empty: http://ftp.debian-ports.org/debian/dists/unreleased/main/source/ No, this is really a corner issue: unreleased is a very small part of the picture. People working on the port can use dget instead of apt-get source, that's really not so cumbersome. Not appearing on buildd.debian.org etc. is way more important to discuss about here. I didn't write this is the main issue, the wording is one of the main problems, I didn't write it wasn't the main issue, I wrote it was a corner issue, i.e. not a main issue. but I wouldn't call it a corner issue. Of course there are other issues of higher importance, not appearing on buildd.debian.org is one, and visibility of bugs (especially with patches) is another. And thus this one is not a main issue, since it's of much lesser importance. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505134208.gb6...@type.labri.fr
Re: Debian Archive architecture removals
Svante Signell, le Tue 05 May 2015 15:00:55 +0200, a écrit : One of the main problems with debian-ports is that the Sources.gz file is empty: http://ftp.debian-ports.org/debian/dists/unreleased/main/source/ No, this is really a corner issue: unreleased is a very small part of the picture. People working on the port can use dget instead of apt-get source, that's really not so cumbersome. Not appearing on buildd.debian.org etc. is way more important to discuss about here. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505130929.gq6...@type.labri.fr
Re: Debian Archive architecture removals
On Tue, 2015-05-05 at 15:09 +0200, Samuel Thibault wrote: Svante Signell, le Tue 05 May 2015 15:00:55 +0200, a écrit : One of the main problems with debian-ports is that the Sources.gz file is empty: http://ftp.debian-ports.org/debian/dists/unreleased/main/source/ No, this is really a corner issue: unreleased is a very small part of the picture. People working on the port can use dget instead of apt-get source, that's really not so cumbersome. Not appearing on buildd.debian.org etc. is way more important to discuss about here. I didn't write this is the main issue, the wording is one of the main problems, but I wouldn't call it a corner issue. Of course there are other issues of higher importance, not appearing on buildd.debian.org is one, and visibility of bugs (especially with patches) is another. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1430833107.4404.158.ca...@gmail.com
Re: Debian Archive architecture removals
On Tue, May 05, 2015 at 09:17:02AM +0200, Samuel Thibault wrote: [Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? That's perhaps the best question to address. Being on master just for being mirrored is not useful to such kinds of ports of course. In the current status of the Debian infrastructure, there are however a lot more consequences, which we can perhaps work on, so as to avoid making hurd-i386 and sparc essentially disappear, and perhaps at the same time to revive some debian-ports archs without overhead for ftp-master, d-release etc.. Also perhaps more easily consider removing more archs from master. I completely agree. And I also agree that moving to debian-ports makes patches harder to get merged, but if debian-ports becomes something more official, it may get slightly easier. Perhaps we need a political decision here? -- Richard Braun -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505123552.gb27...@dalaran.sceen.net
Re: Debian Archive architecture removals
On Tue, May 05, 2015 at 01:36:57PM +0200, Arne Babenhauserheide wrote: Given that the package coverage of the Hurd continuously increased and that it just released 0.6 of its core components[1] along with releasing Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off ftp-master. It's irrelevant. The Hurd isn't a popular system, few people actually use it, there are probably a lot more Debian mirrors than machines using them with hurd-i386 packages. It's simply not worth it. I'm not a Debian contributor but, as a Hurd contributor, it seems perfectly appropriate that the Hurd gets removed from there. On the other hand, I'm ready to provide resources so that things work nicely from debian-ports. -- Richard Braun -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505122710.ga31...@dalaran.sceen.net
Re: Debian Archive architecture removals
Hello, Paul Wise, le Tue 05 May 2015 15:49:36 +0800, a écrit : I haven't seen any resistance to the idea of merging more Debian ports services with the equivalent Debian services, apart from the work needed to do so. Ok. I'm actually realizing one thing: can buildd.debian.org perhaps be made to take its quinn-diff etc. from ftp.debian-ports.org? IIRC, at some point the converse was happening: hurd-i386 was already on master, but we were using buildd.debian-ports.org (which was thus fetching from ftp-master.debian.org, not ftp.debian-ports.org) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505235727.gn2...@type.youpi.perso.aquilenet.fr
Re: Debian Archive architecture removals
+++ Samuel Thibault [2015-05-05 09:17 +0200]:
* Getting binNMUs from d-release transitions
This saves porters a lot of tedious work that would otherwise be just
duplicated. We are not talking about fine-grain binNMUs here, but
coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps
which makes it easy for d-release to just throw them at debian-ports
archs along the master archs and forget about it.
I would just like to second this point, having brought a port through
d-p recently. Keeping up with transition binNMUs is a quite a
significant overhead for a (usually small and overworked) porting
team. As a porter one has a good understanding of arch-specific
issues, but very little understanding of current archive-wide
transitions. And the existing infrastructure doesn't tell you that
things have been rebuilt in the main archive so you should do it too -
you have to poll (or notice when things break/become uninstallable).
It would certainly be an improvement if d-p architectures at least got
notice of such rebuilds (maybe this already could happen, I just
didn't know how?). It would be even better if they automatically
propagated (although this may sometimes break stuff, especially in
early life of a port - some trade-offs there).
Those two previous items may actually perhaps be fixed together:
could it make sense to have the debian-ports architectures on
buildd.debian.org, would it bring human overhead? The databases there
are already per-architecture, so they don't actually interfere.
That's a intresting possibility, but there are also advantages to the
current separate instance/database, config, authorisation and usage
expectations. Merging would fix this issue but might cause others - I
don't know enough to say.
Perhaps we need a political decision here?
I think it's mostly a practical one, as I don't see much disagreement
about the objectives here: What is the best way to arrange things to
support 'released, supported, all-equal' ports vs 'best-effort, let
them get out of sync' 2nd-class ports (both on the way up ('upcoming')
and on the way down ('legacy')).
Centralise the things we can to take workload off porters, distribute
things where ports being broken or unloved could hold up the
released ports.
This is the sort of thing where getting the right people in a room is
productive as hardly anybody has a good overview of all the
aspects/issues. Debconf session?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150505140457.gi18...@halon.org.uk
Re: Debian Archive architecture removals
Perhaps we need a political decision here?
I think it's mostly a practical one, as I don't see much disagreement
about the objectives here: What is the best way to arrange things to
support 'released, supported, all-equal' ports vs 'best-effort, let
them get out of sync' 2nd-class ports (both on the way up ('upcoming')
and on the way down ('legacy')).
It seems to me that second class ports can be divided into three rough
categories, 'new ports that are up and coming' (arm64 and ppc64el were
in this category until recently, x32 could arguablly be included too),
'legacy ports where maintinance has slipped to the point they got kicked
out of the set of first class ports' (alpha, m68k, etc) and 'ports that
despite being around for years never made it to the set of first class
ports' (hurd-i386, ppc64, sparc64, sh4, powerpcspe, argubally x32)
Now on to the political side.
What should the expectations of maintainers of second class ports be?
Should they expect reasonable patches to be merged? who gets to define
reasonable? what if anything should their recourse be if/when
maintainers either ignore or activately stonewall them? is it ok for
maintainers of second class ports to NMU when they are ignored by
package maintainers? if package mtainers stonewall maintainers of second
class ports should they reffer the matter to the technical committe?
Should porter expectations be different between upcoming, legacy,
and never made it ports? should reports be clearly labelled so that
maintainers can quickly tell if the reported problem relates to a first
class or a second class port? should second class ports be labelled
as unofficial?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554945f0.9040...@p10link.net
Re: Debian Archive architecture removals
Samuel Thibault, le Tue 05 May 2015 15:09:29 +0200, a écrit : Svante Signell, le Tue 05 May 2015 15:00:55 +0200, a écrit : One of the main problems with debian-ports is that the Sources.gz file is empty: http://ftp.debian-ports.org/debian/dists/unreleased/main/source/ No, this is really a corner issue: unreleased is a very small part of the picture. Maybe there's one thing you haven't realized: being on master or d-p does not make this issue worse: one can still use deb-src from master to get the sources. This is a matter only for packages uploaded to unreleased, which is meant to be as small as possible. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505165843.gh2...@type.youpi.perso.aquilenet.fr
Re: Debian Archive architecture removals
[Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? That's perhaps the best question to address. Being on master just for being mirrored is not useful to such kinds of ports of course. In the current status of the Debian infrastructure, there are however a lot more consequences, which we can perhaps work on, so as to avoid making hurd-i386 and sparc essentially disappear, and perhaps at the same time to revive some debian-ports archs without overhead for ftp-master, d-release etc.. Also perhaps more easily consider removing more archs from master. * Appearing on packages' and maintainers' PTS pages like http://buildd.debian.org/bash and https://buildd.debian.org/sthiba...@debian.org This makes people aware of portability issues; when hurd-i386 moved there some years ago, that did make a change: we saw maintainers caring and fixing their packages, quite often the fixes are quite trivial. It would be useful to see other debian-ports results there for portability checking, notably hppa. There is already a link to buildd.debian-ports.org, but people do not even notice it, let alone think about checking it. * Getting binNMUs from d-release transitions This saves porters a lot of tedious work that would otherwise be just duplicated. We are not talking about fine-grain binNMUs here, but coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps which makes it easy for d-release to just throw them at debian-ports archs along the master archs and forget about it. Those two previous items may actually perhaps be fixed together: could it make sense to have the debian-ports architectures on buildd.debian.org, would it bring human overhead? The databases there are already per-architecture, so they don't actually interfere. * Appearing on http://release.debian.org/transitions/ and https://qa.debian.org/dose/debcheck/unstable_main/index.html We're fine with d-release not looking at the hurd column. But *we* however do look at it, and would be sad to completely lose that. It could be in a completely separate page or column, that would not pose problem. * Being considered as second-class citizen Well, this is already rather true for hurd-i386: we do sometimes get answers from maintainers this is not going to be a release architecture, I will not bother with patches for it (even about packaging patches). Or the patches linger on the BTS for years (see https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;tag=hurd) Currently we use the important severity for hurd-i386, but maintainers can just discard it. Being on debian-ports actually somehow partly helps here, since we can upload patched packages in unreleased and continue porting. But on the other hand this makes us less pushy, and patches tend to accumulate. Also, being on debian-ports makes it much more difficult to afford making binNMUs, and thus the patches can really linger in the BTS ad æternam. Perhaps we need a political decision here? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505071702.gi3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
On 05/05/15 at 09:17 +0200, Samuel Thibault wrote: * Appearing on packages' and maintainers' PTS pages like http://buildd.debian.org/bash and https://buildd.debian.org/sthiba...@debian.org * Being considered as second-class citizen Note that our developer dashboards (DDPO, Tracker, DMD) are already widely able to pick and combine data from various sources. So as long as the debian-ports data is reliable and useful, I don't think that it would be a problem to expose it more prominently. For example, it would be fairly trivial to add a TODO in https://udd.debian.org/dmd/ or tracker.d.o when there's a package in d-p's unreleased suite _and_ a bug tagged 'hurd' in the BTS. (UDD already knows about all the needed data for that, and I would happily create a json export for tracker to use) - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505073156.ga6...@xanadu.blop.info
Re: Debian Archive architecture removals
On Tue, May 5, 2015 at 3:38 PM, Paul Wise wrote: ... Apologies for the contentless reply. I haven't seen any resistance to the idea of merging more Debian ports services with the equivalent Debian services, apart from the work needed to do so. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gx5nab3ihyorsxhxfzu15wyzqqyswrt6x_nowora0...@mail.gmail.com
Re: Debian Archive architecture removals
On Tue, May 5, 2015 at 3:17 PM, Samuel Thibault sthiba...@debian.org wrote: [Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? That's perhaps the best question to address. Being on master just for being mirrored is not useful to such kinds of ports of course. In the current status of the Debian infrastructure, there are however a lot more consequences, which we can perhaps work on, so as to avoid making hurd-i386 and sparc essentially disappear, and perhaps at the same time to revive some debian-ports archs without overhead for ftp-master, d-release etc.. Also perhaps more easily consider removing more archs from master. * Appearing on packages' and maintainers' PTS pages like http://buildd.debian.org/bash and https://buildd.debian.org/sthiba...@debian.org This makes people aware of portability issues; when hurd-i386 moved there some years ago, that did make a change: we saw maintainers caring and fixing their packages, quite often the fixes are quite trivial. It would be useful to see other debian-ports results there for portability checking, notably hppa. There is already a link to buildd.debian-ports.org, but people do not even notice it, let alone think about checking it. * Getting binNMUs from d-release transitions This saves porters a lot of tedious work that would otherwise be just duplicated. We are not talking about fine-grain binNMUs here, but coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps which makes it easy for d-release to just throw them at debian-ports archs along the master archs and forget about it. Those two previous items may actually perhaps be fixed together: could it make sense to have the debian-ports architectures on buildd.debian.org, would it bring human overhead? The databases there are already per-architecture, so they don't actually interfere. * Appearing on http://release.debian.org/transitions/ and https://qa.debian.org/dose/debcheck/unstable_main/index.html We're fine with d-release not looking at the hurd column. But *we* however do look at it, and would be sad to completely lose that. It could be in a completely separate page or column, that would not pose problem. * Being considered as second-class citizen Well, this is already rather true for hurd-i386: we do sometimes get answers from maintainers this is not going to be a release architecture, I will not bother with patches for it (even about packaging patches). Or the patches linger on the BTS for years (see https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;tag=hurd) Currently we use the important severity for hurd-i386, but maintainers can just discard it. Being on debian-ports actually somehow partly helps here, since we can upload patched packages in unreleased and continue porting. But on the other hand this makes us less pushy, and patches tend to accumulate. Also, being on debian-ports makes it much more difficult to afford making binNMUs, and thus the patches can really linger in the BTS ad æternam. Perhaps we need a political decision here? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505071702.gi3...@type.bordeaux.inria.fr -- bye, pabs https://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/ http://wiki.openmoko.org/wiki/User:PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gqt+y50wi4_d-5gzpvd2c+smr3qpgro8fid_qo2ct...@mail.gmail.com
Re: Debian Archive architecture removals
[ With my debian-ports admin hat ] On 2015-05-04 11:48, Cyril Brulebois wrote: Lucas Nussbaum lu...@debian.org (2015-05-04): I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, First of all it should be noted that moving an architecture to debian-ports, while decreasing the load on ftpmasters, increases the load on debian-ports, so it doesn't change a lot for the project. In practice it even increases as you need more manpower to maintain an architecture in debian-ports than in the debian archive. That's why we should move an architecture to debian-ports only if it some people (DD or not) are really going to maintain it. If not we already have snapshot.debian.org for that. and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. Last I heard about it, it was understaffed and infra was undersized + needed some changes to make it possible to grow. The situation hasn't really changed. Currently the whole debian-ports runs on a single machine, which is a VM kindly provided by DSA. This means running the archive (mini-dak) with http/ftp/rsync, buildd, cdimage and a few more services on a single machine. The machine is therefore heavily loaded, especially I/O wise and we had to disable rsync access except for a few mirrors working in push mode (so that we can control when they do the sync, ie not during mini-dinstall). On the manpower side we are also clearly understaffed, and only working in emergency mode when something is broken. For example the wanna-build installation is usually lacking months of commits compared to the official one. We tried to start addressing with a plan to move services to DSA administrated machine, as it can be seen there: [1]. We started by moving easy things like DNS and website. We then continued by moving the buildd service to a new machine called portman.d.o mimicking as much as possible the layout of the buildd.d.o installation, but we failed to do so in reasonable time. The main issue there is than buildd is a HUGE PAIN to setup as it is actually composed of wanna-build + wbpy + pgstatus + some additional scripts. Add to that some uncommitted code and code running in some $HOME... In addition to that it requires a lot specific setup as root, and thus interaction with DSA. We therefore decided to continue on that at Debconf 15 during a more general sprint [2]. After that we still haven't agreed on how to give access to non-DD people to a DSA administrated machine (see below why I believe it's important). We have some ideas about how to handle the remaining services but no real plan so far. Any help would be appreciated for the move, but also for longterm administration. Of course only serious help, not just unknown persons wanted to be root on debian-ports (yes we get this kind of offer from time to time). What are the current downsides of moving hurd-i386 and sparc to debian-ports? First of all we roughly have two kind of architectures on debian-ports: new architectures which are there for a short time until they get accepted as an official architecture and previously official architectures coming there to die on the longterm. debian-ports has been designed for the first case, where there is usually a lot of manpower. The second case is a bit more recent and started with the removal of official architectures from Debian. I see the following downsides in using debian-ports for an architecture, but they are likely a lot more: - debian-ports uses mini-dak instead of dak. It uses less resources and brings some features that are useful for new architectures like accepting binary uploads when it improves the version even if it is not the latest one or an unreleased suite for packages built from modified source (hence architecture specific). On the contrary its biggest issue is that it is source package based, which means if a package is renamed in a transition this causes the old binary package to disappear and the new one to appear. This causes a lot of extra work for transitions. - Build daemons are not owned by Debian, but have to be provided, hosted and administrated by individuals. It means the machine usually sits on DSL line behind a NAT, that's the reason why debian-ports also provide POP3 mailboxes (yes wanna-build partly communicates by mail). - The above is also true for porter boxes. - Given the above and due to the lack of manpower, more broken time than the official archive. - Transitions are not handled by the release team. - Bug reports concerning these architectures are more often ignored, even if they contain a patch. In addition to that I would like to remind that half of the people actually
Re: Debian Archive architecture removals
On 20/04/15 at 00:22 +0200, Joerg Jaspert wrote: Hi, As the jessie release approaches, the ftp-team have been reviewing the status of the architectures in unstable. Neither sparc nor hurd-i386 are going to release with jessie and we are therefore looking at their future in unstable. SPARC = https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745938 Given the current lack of proper kernel support and the lack of upstream toolchain support, we intend to remove sparc *at the latest*, three months after the release of jessie. This could be avoided if there is a team of Debian Developers putting in a serious effort to revive this port, thus the 3 months timeframe. If this happens, please keep track in an easy reviewable way, so we can recheck it before actual removal (for example list of closed bugs, uploads, upstream patch work, ...). It is noted that the sparc64 port is likely to be a more suitable basis for any future SPARC work but that nobody has approached us about inclusion. hurd-i386 = Well before wheezy was released, we talked with the HURD porters, and they agreed to re-check their archive status just after the wheezy release[1]. The plan was to move the HURD port off ftp-master if it wasn't included as a technology preview or full release arch. HURD wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. We'll be removing HURD, as discussed, from the ftp-master archive after the Jessie release. [1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html Hi, I fully understand that those architectures cause an additional load on ftpmasters (and various other teams). But I've always been very proud that Debian was able to accomodate a wide variety of architectures and kernels (even if I've not done much to achieve that). I find it sad that we will soon have to say oh, and there are also people maintaining an unofficial Hurd port outside Debian. I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? Lucas signature.asc Description: Digital signature
Re: Debian Archive architecture removals
Lucas Nussbaum lu...@debian.org (2015-05-04): I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? Last I heard about it, it was understaffed and infra was undersized + needed some changes to make it possible to grow. This was some time ago, so I've added admin@ to make sure we get updated intel on this topic. Mraw, KiBi. signature.asc Description: Digital signature
Re: Debian Archive architecture removals
On Mon, May 4, 2015 at 5:48 PM, Cyril Brulebois wrote: Lucas Nussbaum lu...@debian.org (2015-05-04): I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? Last I heard about it, it was understaffed and infra was undersized + needed some changes to make it possible to grow. This was some time ago, so I've added admin@ to make sure we get updated intel on this topic. zumbi was working on moving debian-ports to debian.org infrastructure and got some of it done (the website for instance). I asked him about it on IRC and got this response: pabs zumbi: this mail looks like it needs a status update re ports.d.o https://lists.debian.org/20150504062822.ga24...@xanadu.blop.info zumbi pabs: we had this: https://titanpad.com/debian-ports zumbi pabs: I was hoping for debcamp/debconf to be able to finish it up zumbi (however I am still unsure about if I'll be able to attend event) pabs zumbi: may I copy that into email or can you? zumbi pabs: feel free to copy it zumbi pabs: it needs someone with wanna-build database experience, some dsa, aurel32 (and maybe some ftp-master) to complete the work -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FXYe0te=rE-2B0-8OCgdG=tut_et66mkhu6rgnjwc...@mail.gmail.com
Re: Debian Archive architecture removals
On 04/05/15 at 18:04 +0800, Paul Wise wrote: On Mon, May 4, 2015 at 5:48 PM, Cyril Brulebois wrote: Lucas Nussbaum lu...@debian.org (2015-05-04): I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? Last I heard about it, it was understaffed and infra was undersized + needed some changes to make it possible to grow. This was some time ago, so I've added admin@ to make sure we get updated intel on this topic. zumbi was working on moving debian-ports to debian.org infrastructure and got some of it done (the website for instance). I asked him about it on IRC and got this response: pabs zumbi: this mail looks like it needs a status update re ports.d.o https://lists.debian.org/20150504062822.ga24...@xanadu.blop.info zumbi pabs: we had this: https://titanpad.com/debian-ports zumbi pabs: I was hoping for debcamp/debconf to be able to finish it up zumbi (however I am still unsure about if I'll be able to attend event) pabs zumbi: may I copy that into email or can you? zumbi pabs: feel free to copy it zumbi pabs: it needs someone with wanna-build database experience, some dsa, aurel32 (and maybe some ftp-master) to complete the work That pad says: As a result of current state, d-ports cannot accept more ports. If that's still true, it would make sense to postpone dropping hurd and sparc until this is fixed... Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504104741.ga18...@xanadu.blop.info
Re: Debian Archive architecture removals
+++ Lucas Nussbaum [2015-05-04 12:47 +0200]: On 04/05/15 at 18:04 +0800, Paul Wise wrote: On Mon, May 4, 2015 at 5:48 PM, Cyril Brulebois wrote: Lucas Nussbaum lu...@debian.org (2015-05-04): I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. I think that's the right way to do it, and the way things are, in practice, done. zumbi was working on moving debian-ports to debian.org infrastructure pabs zumbi: this mail looks like it needs a status update re ports.d.o https://lists.debian.org/20150504062822.ga24...@xanadu.blop.info zumbi pabs: we had this: https://titanpad.com/debian-ports That pad says: As a result of current state, d-ports cannot accept more ports. If that's still true, it would make sense to postpone dropping hurd and sparc until this is fixed... Was that before or after arm64 and ppc64el migrated off ports to the main archive? That should have freed up some space and resource? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504152815.gy18...@halon.org.uk
Re: Debian Archive architecture removals
On 13931 March 1977, Lucas Nussbaum wrote: That pad says: As a result of current state, d-ports cannot accept more ports. If that's still true, it would make sense to postpone dropping hurd and sparc until this is fixed... Hurd is already on d-p, so hurd actually has double infrastructure use. And the last release they did came from d-p resources, which is another argument not to continue on ftp-master with them. Sparc has sparc64 there, so that would be an addition to it. -- bye, Joerg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87pp6gs4pa@delenn.ganneff.de
Re: Debian Archive architecture removals
Joerg Jaspert, le Mon 04 May 2015 18:11:29 +0200, a écrit : On 13931 March 1977, Lucas Nussbaum wrote: That pad says: As a result of current state, d-ports cannot accept more ports. If that's still true, it would make sense to postpone dropping hurd and sparc until this is fixed... Hurd is already on d-p, so hurd actually has double infrastructure use. Not really: we only have a dozen packages on d-p, the rest is not on d-p. And the last release they did came from d-p resources, No, I got the packages from master, and used snapshot.d.o as a way to have a frozen image of it. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504161609.gk3...@type.bordeaux.inria.fr
Re: Re: Debian Archive architecture removals
Was that before or after arm64 and ppc64el migrated off ports to the main archive? I'm pretty sure ppc64el was never on debian-ports, it went straight from an IBM run repository to the main archive. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55481c57.4010...@p10link.net
Re: Debian Archive architecture removals
Hello, Joerg Jaspert, le Mon 20 Apr 2015 00:22:08 +0200, a écrit : hurd-i386 = Well before wheezy was released, we talked with the HURD porters, and they agreed to re-check their archive status just after the wheezy release[1]. The plan was to move the HURD port off ftp-master if it wasn't included as a technology preview or full release arch. HURD wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. We'll be removing HURD, as discussed, from the ftp-master archive after the Jessie release. [1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html I was thinking about coordinating a reply to this from the Hurd team, so went back to re-read that thread from 2 years ago, and then got reminded what bad time it happened at, and don't want to repeat that again. I believe there is some discussion we want to have about debian architecture ports, but can we delay that to *after* having happily celebrated the Jessie release? Thanks, Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150420195221.ge3...@type.youpi.perso.aquilenet.fr
Debian Archive architecture removals
Hi, As the jessie release approaches, the ftp-team have been reviewing the status of the architectures in unstable. Neither sparc nor hurd-i386 are going to release with jessie and we are therefore looking at their future in unstable. SPARC = https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745938 Given the current lack of proper kernel support and the lack of upstream toolchain support, we intend to remove sparc *at the latest*, three months after the release of jessie. This could be avoided if there is a team of Debian Developers putting in a serious effort to revive this port, thus the 3 months timeframe. If this happens, please keep track in an easy reviewable way, so we can recheck it before actual removal (for example list of closed bugs, uploads, upstream patch work, ...). It is noted that the sparc64 port is likely to be a more suitable basis for any future SPARC work but that nobody has approached us about inclusion. hurd-i386 = Well before wheezy was released, we talked with the HURD porters, and they agreed to re-check their archive status just after the wheezy release[1]. The plan was to move the HURD port off ftp-master if it wasn't included as a technology preview or full release arch. HURD wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. We'll be removing HURD, as discussed, from the ftp-master archive after the Jessie release. [1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html -- bye, Joerg Throw them away? Are you mad woman? You never know when an old calendar may come in handy. Sure it’s not 1985 now, but who knows what tomorrow might bring? signature.asc Description: PGP signature
