Re: Alioth tracker
Le 25/06/2014 08:49, Raphael Hertzog a écrit : > This happened a few times already but only with well know DD. For what it's worth, Ole is well known an respected in the area in which he has contributed most, the Debian Astro team, which he created. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Re: Alioth tracker
On Wed, 25 Jun 2014, Raphael Hertzog wrote: > FTR I used to be an Alioth admin, so I have some experience with the > work involved. > > On Wed, 25 Jun 2014, Russell Stuart wrote: > > Sorry to be blunt Raphael, but your response looks like a series of > > platitudes designed to settle down the politics. Alioth's maintenance > > is in serious trouble. It is unusable to many projects on it, and it is > > clear from it's own bug reporting systems this has been the case for > > years. > > You're painting a picture which is worse than the reality. I agree > that nobody is looking at the tickets regularly and that mails to > ad...@alioth.debian.org tends to not get an answer but there are admins > and they are not entirely unavailable. Up to now I always managed to get > answer to my requests even though if often requires pinging the admins > via #alioth. > > > Deciding to accept an offer of help requires a lot of work. You have to > > find a graduated set of tasks that allows you to gain confidence in the > > persons abilities, and closely monitor how well they perform them. It > > looks to me like the effort required is beyond the Alioth team. > > That's true, it's difficult to get enough confidence in someone that > has not some history of contribution and to give them root rights. > > On Wed, 25 Jun 2014, Matthias Urlichs wrote: > > In this case, gradually transitioning people to admins probably won't work: > > somebody needs to monitor the new guys+gals and give them a couple of > > rights to start with … and then, after some time, a couple of more rights … > > and who says that my "I want to help" request will be looked at, much less > > my "I'm ready for more opportunities to cause untold damage, give them to > > me" mail, next month? > > > > Instead, get a couple of volunteers and give them full admin rights from > > the start. Some will blunder their way through and some will quit after a > > week, but when the shakedown is done there's at least a chance that some of > > them will stay with it (and not break things too badly). > > This happened a few times already but only with well know DD. Cyril > Brulebois got root rights over night after having > provided a few patches to multiple configuration files. I believe he > dropped off quickly because he does many other things already but still... > Alexander Wirt also joined the team not so long ago > AFAIK. More or less. If I am around and if things are possible without too much insight into fusionforge I am trying to help as much as I can. I really need some time to get more knowledge about fusionforge. Alex -- 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/20140625065431.gj21...@formorer.de
Re: Alioth tracker
FTR I used to be an Alioth admin, so I have some experience with the work involved. On Wed, 25 Jun 2014, Russell Stuart wrote: > Sorry to be blunt Raphael, but your response looks like a series of > platitudes designed to settle down the politics. Alioth's maintenance > is in serious trouble. It is unusable to many projects on it, and it is > clear from it's own bug reporting systems this has been the case for > years. You're painting a picture which is worse than the reality. I agree that nobody is looking at the tickets regularly and that mails to ad...@alioth.debian.org tends to not get an answer but there are admins and they are not entirely unavailable. Up to now I always managed to get answer to my requests even though if often requires pinging the admins via #alioth. > Deciding to accept an offer of help requires a lot of work. You have to > find a graduated set of tasks that allows you to gain confidence in the > persons abilities, and closely monitor how well they perform them. It > looks to me like the effort required is beyond the Alioth team. That's true, it's difficult to get enough confidence in someone that has not some history of contribution and to give them root rights. On Wed, 25 Jun 2014, Matthias Urlichs wrote: > In this case, gradually transitioning people to admins probably won't work: > somebody needs to monitor the new guys+gals and give them a couple of > rights to start with … and then, after some time, a couple of more rights … > and who says that my "I want to help" request will be looked at, much less > my "I'm ready for more opportunities to cause untold damage, give them to > me" mail, next month? > > Instead, get a couple of volunteers and give them full admin rights from > the start. Some will blunder their way through and some will quit after a > week, but when the shakedown is done there's at least a chance that some of > them will stay with it (and not break things too badly). This happened a few times already but only with well know DD. Cyril Brulebois got root rights over night after having provided a few patches to multiple configuration files. I believe he dropped off quickly because he does many other things already but still... Alexander Wirt also joined the team not so long ago AFAIK. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140625064934.gi7...@x230-buxy.home.ouaza.com
Re: Alioth tracker
Hi, Raphael Hertzog: > On Tue, 24 Jun 2014, Оlе Ѕtrеісhеr wrote: > > I thought that usually such requests should be done through an request > > for help? (Is that valid for "pseudo packages" like a hypothetical > > alioth one?) If the alioth admin team would openly request for help > > (maybe on the Debian-News?), they may gain more attention for that. > > Most infrastructure teams are always looking for help, wether they send > explicit calls for help or not. And even more so when they are not working > properly. > Hmm. When I see 'easy' bug reports that have not been processed for a whole year, I will not conclude "this project needs help". Instead, I see "this project is dead", and will find some other place to host my repository and bug tracker. In this case, gradually transitioning people to admins probably won't work: somebody needs to monitor the new guys+gals and give them a couple of rights to start with … and then, after some time, a couple of more rights … and who says that my "I want to help" request will be looked at, much less my "I'm ready for more opportunities to cause untold damage, give them to me" mail, next month? Instead, get a couple of volunteers and give them full admin rights from the start. Some will blunder their way through and some will quit after a week, but when the shakedown is done there's at least a chance that some of them will stay with it (and not break things too badly). -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Alioth tracker
On Tue, 2014-06-24 at 18:05 +0200, Raphael Hertzog wrote: > On Tue, 24 Jun 2014, Оlе Ѕtrеісhеr wrote: > > I thought that usually such requests should be done through an request > > for help? (Is that valid for "pseudo packages" like a hypothetical > > alioth one?) If the alioth admin team would openly request for help > > (maybe on the Debian-News?), they may gain more attention for that. > > Most infrastructure teams are always looking for help, wether they send > explicit calls for help or not. And even more so when they are not working > properly. Sorry to be blunt Raphael, but your response looks like a series of platitudes designed to settle down the politics. Alioth's maintenance is in serious trouble. It is unusable to many projects on it, and it is clear from it's own bug reporting systems this has been the case for years. Deciding to accept an offer of help requires a lot of work. You have to find a graduated set of tasks that allows you to gain confidence in the persons abilities, and closely monitor how well they perform them. It looks to me like the effort required is beyond the Alioth team. I say that because I had a similar experience to Ole, which I reported here [0], on IRC and on Alioth's bug tracker [1]. They all included offers to help. AFAICT the bug reports have never been looked at. The only response I got here was from Paul Wise [2] who said my negative impressions of sourceforge were outdated. (Well done Ole - you managed to elicit a better response than me.) In the end it doesn't matter I guess. Unlike the other core Debian facilities there are lots of well known alternatives out there so Alioth isn't really needed. I tried 3 of them (4 if you count Alioth) moving on from each after trying to put a project on them and finding then deficient. Thanks to Paul's advice I tried SourceForge in the end, and so far it has worked out well [3]. Thanks Paul - that response really helped. Ole - I suggest you do the same. [0] https://lists.debian.org/debian-devel/2014/05/msg00463.html [1] https://alioth.debian.org/tracker/index.php?func=detail&aid=314680&group_id=1&atid=21 [2] https://lists.debian.org/debian-devel/2014/05/msg00464.html [3] http://sourceforge.net/u/rstuart/profile/ signature.asc Description: This is a digitally signed message part
Re: Alioth tracker
On Tue, 24 Jun 2014, Оlе Ѕtrеісhеr wrote: > I thought that usually such requests should be done through an request > for help? (Is that valid for "pseudo packages" like a hypothetical > alioth one?) If the alioth admin team would openly request for help > (maybe on the Debian-News?), they may gain more attention for that. Most infrastructure teams are always looking for help, wether they send explicit calls for help or not. And even more so when they are not working properly. > I don't know anything about the internals of alioth, and from a quick > view into the issues I am not capable to help there. I would probably > break more that I could fix. This is not really compatible with your analysis saying that half of the tickets are trivial to fix (with the proper rights). > Hmm, I thought that the bug tracker *is* actually made for interaction > with the admins. I would also again raise the point: why does alioth > have its own tracker and does not use the Debian bug tracking system? It's an historic decision. The idea was to use our own dogfood. If alioth admins don't know anything about the ticket system, they can hardly help the teams which are using it (or for that matter, ensure that the ticket system works). That said I agree that it was a bad decision because most Debian teams do not use the ticket tracker anyway and this difference with other Debian teams create a useless barrier for contribution. It's also much more restricted than the Debian BTS and makes it difficult for other to help with triaging Alioth issues (which is bad when the team is understaffed/too busy with other things). > If we would > > * create a pseudo package for alioth, and use that for bug reports and > support requests What do you alioth admins think? Would you agree to switch to a pseudo-package in the BTS? > Also, there are ~75 requests like > > * Please fix permissions/ACL/group of project xyz With latest fusionforge, admins should be able to grant right to other teams with the permission/public role system and ACL are in theory not needed. I know it wasn't working very well with the Debian group which was very large... I don't know if things improved or if ACL are still needed here. > * Please remove project xyz > * Please remove user abc > > They would require some confirmation that the request is valid, but are > then done within a minute. This would already decrease the number of > open requests by half! There is no other way than to have trusted admins > to handle these cases. Good point, without the ticket system it's difficult to authenticate such requests. Maybe removal requests should still be handled via the Alioth tickets even if we have a BTS pseudo-package. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140624160508.ga8...@x230-buxy.home.ouaza.com
Re: Alioth tracker
Raphael Hertzog writes: > On Tue, 24 Jun 2014, Ole Streicher wrote: >> I can imagine that behind any of the tickets on alioth there is a story >> like this, so I don't want to bring my one onto the front. >> So, how do we get rid of the ~200 open support requests? > > Join the team handling alioth and start working on those issues. I thought that usually such requests should be done through an request for help? (Is that valid for "pseudo packages" like a hypothetical alioth one?) If the alioth admin team would openly request for help (maybe on the Debian-News?), they may gain more attention for that. I don't know anything about the internals of alioth, and from a quick view into the issues I am not capable to help there. I would probably break more that I could fix. > Quite a few of the problems can be investigated without any special admin > right. For the rest, some friendly interaction with current admins > (for example via IRC on #alioth) might help them and might convince > them to give you more rights. Hmm, I thought that the bug tracker *is* actually made for interaction with the admins. I would also again raise the point: why does alioth have its own tracker and does not use the Debian bug tracking system? > It's probably not the answer you were looking for. But we need people > to do the work obviously. If we would * create a pseudo package for alioth, and use that for bug reports and support requests * create a mailing list for all other communication (like the latest one: [#314699] reverse DNS entry for IPv6 [...]?) it would be much simpler to get the work done. To give some overview about the nature of the requests: Currently, 182 requests are open. From them, 8 are obviously spam: 314476, 314399, 314396, 314395, 314394, 314390, 314389, 314430 They are in the ticket database since a year, which shows that noone of the admins actually looked through the request for such a long time! Even these bugs can only be closed by the admins (not by me) -- and if they were on bugs.debian.org, one just could hit the "report as spam" button. Also, there are ~75 requests like * Please fix permissions/ACL/group of project xyz * Please remove project xyz * Please remove user abc They would require some confirmation that the request is valid, but are then done within a minute. This would already decrease the number of open requests by half! There is no other way than to have trusted admins to handle these cases. Especially the "Fix permission" tasks (~25) are critical here since they usually prevent people from actually accessing repositories, and the repositories are the main workspace for us packagers! The other ~100 requests are * E-mail problems (mail lost, mailing list access etc.) * Configuration change requests * Software extension proposals * Bugreports on the used software which seem to take more work. If one counts only the problems (bugreports or e-mail problems, this may be something of 40 requests. BTW, the last issue that was actively closed by an alioth admin was on August 2013 [#314410]. I don't see that your proposal would really solve the problem. Best Ole -- 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/ytz38euphbi@news.ole.ath.cx
Re: Re: Alioth tracker
On Tue, 24 Jun 2014, Ole Streicher wrote: > I can imagine that behind any of the tickets on alioth there is a story > like this, so I don't want to bring my one onto the front. > > So, how do we get rid of the ~200 open support requests? Join the team handling alioth and start working on those issues. Quite a few of the problems can be investigated without any special admin right. For the rest, some friendly interaction with current admins (for example via IRC on #alioth) might help them and might convince them to give you more rights. It's probably not the answer you were looking for. But we need people to do the work obviously. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140624120921.ga21...@x230-buxy.home.ouaza.com
Re: Re: Alioth tracker
Hi Tollef and all, > I'm not disagreeing, I think we're providing a much poorer service level > for Alioth than what we should do. Sadly, I don't have the motivation > to spend much time there nowadays. So what should we do here? Since you are listed as the first person on the "site admin" page of alioth, I now feel a bit helpless and frustrated. Does the comment above mean that you are actually giving up alioth management? We started the debian-astro project a few months ago, and we are full of enthusiasm to make it a good project. I myself can live with that my git repositories are not visible on the web for a few weeks, but I don't see this changing for the next age. And there are other that just want to start [1] and get confused by the situation. How shall I convince people to join the project if we cannot fix the problems that appear? What should we do? Move avay from a poorly administrated site and organize ourself somewhere outside? I can imagine that behind any of the tickets on alioth there is a story like this, so I don't want to bring my one onto the front. So, how do we get rid of the ~200 open support requests? Best regards Ole [1] https://lists.debian.org/debian-astro/2014/06/msg00013.html -- Ole Streicher Tel: +49 331 7499-666, Fax: -429 http://www.aip.de Leibniz-Institut für Astrophysik Potsdam (AIP) An der Sternwarte 16, 14482 Potsdam, Germany Vorstand: Prof. Dr. Matthias Steinmetz, Dr. Ulrich Müller Stiftung bürgerlichen Rechts Stiftungsverzeichnis Brandenburg: 26 742-00/7026 -- 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/53a93300.3050...@liska.ath.cx
Re: mailman3 in Debian [was Re: Alioth tracker]
On May 12, 2014, at 05:46 PM, Thijs Kinkhorst wrote: >Mailman 3 is completely different from Mailman 3 and I see no synergy in >basing anything on the existing package. As of now, to my knowledge no >migration or upgrade scenarios exist from MM 2 to MM 3, and I'm not sure >if such code will be there in time for jessie. We do have code in the core to do updates from 2.1 to 3. It's well unit tested, but not battle tested. >It would therefore make most sense to me if MM 3 packaging was started fresh >with a new mailman3 package, allowing for both MM3 and the legacy release to >coexist while MM3 matures. When reliable upgrade or migration scenarios >exist, the mailman3 package could take over the mailman package, but I expect >that to be the case only after jessie. > >People interested in MM 3 are therefore very much invited to just start >packaging it under the mailman3 name, in any way they judge best. Agreed. The MM3 core is a well-behaved setuptools-based project so its packaging should be relatively easy. Hyperkitty and Postorius are Django-based applications. We (upstream) very definitely expect that people will want to run existing MM2.1 installations in parallel with MM3, at least for a while or while they're testing out the transition. I may not have time in the immediate future to do the packaging myself, but I will assist others in any way I can. -Barry signature.asc Description: PGP signature
Re: mailman3 in Debian [was Re: Alioth tracker]
On Mon, May 12, 2014 17:00, Clint Adams wrote: > On Mon, May 12, 2014 at 10:02:35AM -0400, Barry Warsaw wrote: >> I don't have time to work on Alioth, but JFTR, we (the GNU Mailman >> development team) recently announced the first full-suite beta release >> for Mailman 3. It's possible that even with the usual beta-quality >> issues, that MM3 would make a decent mailing list framework for this >> Debian use case. It has some interesting features that might make >> integration easier, and I would be highly motivated to help others adapt >> and extend MM3 for Debian's use. > > Are there plans to upload packages to experimental? Some considerations on behalf of the current "Mailman for Debian" 'team' which maintains the mailman 2.x packages in Debian. The current mailman 2.x packaging is dated and in maintenance mode, updating to the infrequent new upstreams of this branch and fixing the occasional bug, and having not much manpower to do much else. Mailman 3 is completely different from Mailman 3 and I see no synergy in basing anything on the existing package. As of now, to my knowledge no migration or upgrade scenarios exist from MM 2 to MM 3, and I'm not sure if such code will be there in time for jessie. It would therefore make most sense to me if MM 3 packaging was started fresh with a new mailman3 package, allowing for both MM3 and the legacy release to coexist while MM3 matures. When reliable upgrade or migration scenarios exist, the mailman3 package could take over the mailman package, but I expect that to be the case only after jessie. People interested in MM 3 are therefore very much invited to just start packaging it under the mailman3 name, in any way they judge best. Cheers, Thijs -- 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/d47c67ad31ddbafccab5a96782a02618.squir...@aphrodite.kinkhorst.nl
mailman3 in Debian [was Re: Alioth tracker]
On Mon, May 12, 2014 at 10:02:35AM -0400, Barry Warsaw wrote: > I don't have time to work on Alioth, but JFTR, we (the GNU Mailman development > team) recently announced the first full-suite beta release for Mailman 3. > It's possible that even with the usual beta-quality issues, that MM3 would > make a decent mailing list framework for this Debian use case. It has some > interesting features that might make integration easier, and I would be highly > motivated to help others adapt and extend MM3 for Debian's use. Are there plans to upload packages to experimental? -- 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/20140512150028.ga15...@scru.org
Re: Alioth tracker
On May 12, 2014, at 07:57 AM, Charles Plessy wrote: >For mailing lists, I read in the thread that it may not be a problem anyway, >but I just wanted to add one thing: in many cases the lists to be created are >a maintainer list and a commit list, and this could be replaced completely by >the “new PTS” (see http://dep.debian.net/deps/dep2/ and >http://pts.debian.net/). People who have time to give but do not have the >right skill set to work on Alioth or Mailman may consider helping the new PTS >instead. I don't have time to work on Alioth, but JFTR, we (the GNU Mailman development team) recently announced the first full-suite beta release for Mailman 3. It's possible that even with the usual beta-quality issues, that MM3 would make a decent mailing list framework for this Debian use case. It has some interesting features that might make integration easier, and I would be highly motivated to help others adapt and extend MM3 for Debian's use. Contact me personally off-list or via IRC, or start the discussion on the mailman-develop...@python.org list. Cheers, -Barry signature.asc Description: PGP signature
Re: Alioth tracker
On Mon, May 12, 2014 at 8:27 AM, Russell Stuart wrote: > sourceforge is closed source. That is no longer the case, sourceforge folks implemented a new codebase called Allura, are running it, released it under the Apache license and continue to develop it as an Apache Software Foundation project. http://allura.apache.org/ http://sourceforge.net/projects/allura/ > B. A backup system. The Debian sysadmins have backups of alioth in place. -- bye, pabs http://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/CAKTje6EJEJErnnc4f=E5v=-g6ylfzv1fmestmeknthvqdog...@mail.gmail.com
Re: Alioth tracker
On Sun, 2014-05-11 at 21:38 +0200, Tollef Fog Heen wrote: > I'm not disagreeing, I think we're providing a much poorer service level > for Alioth than what we should do. Sadly, I don't have the motivation > to spend much time there nowadays. I have for years hosted my own projects in a minimalistic fashion [0], and as a consequence have been nagged to provide "modern amenities" like issue trackers and DCVS. The obvious solution would be to move to free hosting like sourceforge, but sourceforge is closed source. Then I joined Debian. Alioth seemed like a natural fit, so I started moving my projects to it. But now I've decided that's not such a good idea. Not because of some of the issues mentioned in this thread - like DVCS support of lacking features in Fusion Forge. I can work around them. My problem is Alioth isn't reliable enough. In week or so I used it: a. As Ole mentioned, there are 180 odd open support requests, dating back 7 years. It's not that things aren't being done - Stephen Gran in particular appears to regularly attend to the list and close issues. However, there should be no support requests open for more than a few weeks (and ideally at most a couple of days). Many of these old "support requests" are bugs or features, and there are separate trackers for those. In other words, the support list needs to be triaged. If after triage there are still support requests more than a month old, the clearly Alioth needs extra admin manpower. Right now it is difficult to tell if manpower is really the issue. b. For a while when I was using it is was horribly slow (as in taking minutes to send a response to a HTTP request). I could not see why. After a day or so the issue went away and it because usable again. c. Then I started getting mysterious failures. After a bit of digging around I noticed /tmp was at 100%. Someone fixed this after a few hours. d. At the same time I noticed disk space it is sitting 94% usage. The amount of disk used is under 600GB. e. I suspect running out of disk space on /tmp caused a number of other issues for me [1]. The details aren't relevant here. What is relevant is in order to diagnose what was going I poked around the file system, and noticed a number of other much older projects were suffering from the same issues. Since this means among other things they can't use the DVCS, presumably they had been abandoned. f. After seeing all this, I decided I had better do some "due diligence" and what backup arrangements were in place. As far as I can tell there aren't any. At this point I reluctantly decided I had to use why I was trying to avoid - a commercial provider running close source. If three things changed on Alioth I would move back. They are: A. Solve the disk space problems. B. A backup system. C. Support list triaged, and it's length viewed as a KPI. If the Alioth team thinks I could be useful in getting this things done, I'd be happy to become part of it. Even if they don't, I'd be happy to donate 2 x 4TB drives so the disk space issue can be fixed - assuming there are remote hands available to fit them. [0] http://www.stuart.id.au/russell/files [1] https://alioth.debian.org/tracker/index.php?func=detail&aid=314680&group_id=1&atid=21 signature.asc Description: This is a digitally signed message part
Re: Alioth tracker
Le Sun, May 11, 2014 at 03:58:50PM +0200, Daniel Pocock a écrit : > > Other people have had problems with alioth too: > > - write permissions on VCS directory for new projects > > - mailing list creation requests waiting for admin approval Thanks Daniel for raising the issue. For mailing lists, I read in the thread that it may not be a problem anyway, but I just wanted to add one thing: in many cases the lists to be created are a maintainer list and a commit list, and this could be replaced completely by the “new PTS” (see http://dep.debian.net/deps/dep2/ and http://pts.debian.net/). People who have time to give but do not have the right skill set to work on Alioth or Mailman may consider helping the new PTS instead. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140511225715.gb13...@falafel.plessy.net
Re: Alioth tracker
]] Daniel Pocock > On 11/05/14 18:26, Tollef Fog Heen wrote: > > ]] Daniel Pocock > > > >> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote: > >> > >>> What is the reason that the processing there is so slow? Is there a way > >>> to change that? > > > > I think it's quite clear and has been for a while that we need more > > active admins for Alioth. > > > >> Other people have had problems with alioth too: > >> > >> - write permissions on VCS directory for new projects > >> > >> - mailing list creation requests waiting for admin approval > > > > Mailing lists are managed through gforge and there's no manual approval > > process that I know of. > > > When creating a list, it tells me the list will be approved within 6-24 > hours Hmm, I think that approval is automatic. At least I haven't seen any nagging from fusionforge to approve mailing lists. > >> Any of these things could help reduce the admin burden, maybe there are > >> other approaches too? > > > > Help fix bugs in fusionforge, hang out in #alioth try to help people and > > we'd be happy to get more people involved. > > If people have not already stepped forward to fill these gaps then that > is the very reason why I was suggesting further automation or cutting > back on things like legacy VCS support. Automating things takes effort too. > Hopefully the burden of support and the capacity of volunteers will then > converge at a point where it is sustainable. > > I'm not criticizing anybody for this situation, nor am I trying to prod > anybody into action - I just feel that if volunteers are limited, it is > better to constrain the scope of the service. I'm not disagreeing, I think we're providing a much poorer service level for Alioth than what we should do. Sadly, I don't have the motivation to spend much time there nowadays. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87bnv4nm0l@xoog.err.no
Re: Alioth tracker
On 11/05/14 18:26, Tollef Fog Heen wrote: > ]] Daniel Pocock > >> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote: >> >>> What is the reason that the processing there is so slow? Is there a way >>> to change that? > > I think it's quite clear and has been for a while that we need more > active admins for Alioth. > >> Other people have had problems with alioth too: >> >> - write permissions on VCS directory for new projects >> >> - mailing list creation requests waiting for admin approval > > Mailing lists are managed through gforge and there's no manual approval > process that I know of. When creating a list, it tells me the list will be approved within 6-24 hours Previously when I created lists, I would receive an email from mailman some hours later giving me the list password - this is the usual mailman behavior when the mailman site admin approves a list. Maybe that is entirely within mailman and not gforge. >> Any of these things could help reduce the admin burden, maybe there are >> other approaches too? > > Help fix bugs in fusionforge, hang out in #alioth try to help people and > we'd be happy to get more people involved. If people have not already stepped forward to fill these gaps then that is the very reason why I was suggesting further automation or cutting back on things like legacy VCS support. Hopefully the burden of support and the capacity of volunteers will then converge at a point where it is sustainable. I'm not criticizing anybody for this situation, nor am I trying to prod anybody into action - I just feel that if volunteers are limited, it is better to constrain the scope of the service. -- 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/536fd070.1090...@pocock.pro
Re: Alioth tracker
]] Daniel Pocock > On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote: > > > What is the reason that the processing there is so slow? Is there a way > > to change that? I think it's quite clear and has been for a while that we need more active admins for Alioth. > Other people have had problems with alioth too: > > - write permissions on VCS directory for new projects > > - mailing list creation requests waiting for admin approval Mailing lists are managed through gforge and there's no manual approval process that I know of. > Any of these things could help reduce the admin burden, maybe there are > other approaches too? Help fix bugs in fusionforge, hang out in #alioth try to help people and we'd be happy to get more people involved. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2bnv4jn8e@rahvafeir.err.no
Re: Alioth tracker
Quoting Daniel Pocock (2014-05-11 15:58:50) > On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote: >> is someone processing the items on the Alioth tracker? Thanks for raising that general question here, Ole. I have been wondering too. > Other people have had problems with alioth too: [details snipped] Please, for each item, refer to its bugreport, to encourage moving discussions on details to that bugreport, and only discuss the overview here. The way you present it has a high risk of being interpreted as whining (which I am confident wasn't your intention). > On non-Debian sites (e.g. Sourceforge, github) things like this are > fully automated (for better or worse). I believe some of the issues you mentioned has been recently been automated - but I prefer handling the details at each bugreport. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Alioth tracker
Hi, Am Sonntag, den 11.05.2014, 15:58 +0200 schrieb Daniel Pocock: > > On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote: > > Hi, > > > > is someone processing the items on the Alioth tracker? [...] > > Other people have had problems with alioth too: > > - write permissions on VCS directory for new projects and by takeover as new maintainer. It's really not good that a new package version is online and in Vcs is only a old version. > > - mailing list creation requests waiting for admin approval > > On non-Debian sites (e.g. Sourceforge, github) things like this are > fully automated (for better or worse). > [...] > For repositories: > - would moving to a single tool (e.g. Git) make it easier to automate > and help to eliminate the bugs we currently see on alioth? > - could we have a debian.org solution (alioth or elsewhere) that > automatically mirrors all Git repositories that DDs maintain themselves > on github or other public locations? and / or DD can approve the rights to the maintainers. > Any of these things could help reduce the admin burden, maybe there are > other approaches too? +1 Regards, Jörg -- pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8 EBCB 422B 44B0 BE58 1B6E pgp Key: BE581B6E CAcert Key S/N: 0E:D4:56 Jörg Frings-Fürst D-54526 Niederkail IRC: j_...@freenode.net j_...@oftc.net signature.asc Description: This is a digitally signed message part
Re: Alioth tracker
On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote: > Hi, > > is someone processing the items on the Alioth tracker? > > There are currently 184 reuqests open, some trivial requests already > since two years (like [1]). > > I filed a ticket there a month ago, and still did not get any > response yet. > > What is the reason that the processing there is so slow? Is there a way > to change that? > > Also, although alioth is an official Debian server (right? It has .org > suffix), it does not use the Debian bug system, but its own ticket > system. I asked that already some time ago, and got the recommendation > to ask that on alioth directly. However, since the response time there > is so long, I doubt that there will be a discussion about this. > Other people have had problems with alioth too: - write permissions on VCS directory for new projects - mailing list creation requests waiting for admin approval On non-Debian sites (e.g. Sourceforge, github) things like this are fully automated (for better or worse). For mailing lists: - could list creation be fully automated if they are on a debian.net subdomain? - could all DDs be given rights to approve alioth.d.o mailing list creation (with a dispute process for any controversial approvals)? For repositories: - would moving to a single tool (e.g. Git) make it easier to automate and help to eliminate the bugs we currently see on alioth? - could we have a debian.org solution (alioth or elsewhere) that automatically mirrors all Git repositories that DDs maintain themselves on github or other public locations? Any of these things could help reduce the admin burden, maybe there are other approaches too? -- 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/536f821a.5030...@pocock.pro
Alioth tracker
Hi, is someone processing the items on the Alioth tracker? There are currently 184 reuqests open, some trivial requests already since two years (like [1]). I filed a ticket there a month ago, and still did not get any response yet. What is the reason that the processing there is so slow? Is there a way to change that? Also, although alioth is an official Debian server (right? It has .org suffix), it does not use the Debian bug system, but its own ticket system. I asked that already some time ago, and got the recommendation to ask that on alioth directly. However, since the response time there is so long, I doubt that there will be a discussion about this. Best regards Ole [1] https://alioth.debian.org/tracker/index.php?func=detail&aid=313806 -- 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/ytzr444sgzb@news.ole.ath.cx
Re: Alioth Tracker: no correspondence to BTS?
Hello, On Sun, 09.07.2006 at 22:15:40 +0200, Christian Perrier <[EMAIL PROTECTED]> wrote: > We (iso-codes maintenance team and, more precisely Tobias Toedter) > discovered that some people reported bugs in the Alioth BTS (or > tracker?) without us even knowing about it..:-) I've seen a very similar problem. That's why I asked... > The action has of course been to re-report these to the Debian BTS > andshut down the feature. Good idea. > Of course, this makes me think that the feature should indeed be > disabled by default in new projects. Seconded! Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alioth Tracker: no correspondence to BTS?
Peter Samuelson, 2006-07-09 21:30:11 +0200 : > [Toni Mueller] >> I've just poked around a bit in Alioth for a project I'm working on >> and found a bug report with a bug number that has no resemblance to >> anything in BTS, quite contrary to my initial assumption. > > Yeah, the sourceforge software includes a primitive bug tracker > which, as far as I know, people don't really use on alioth. Some do (the Alioth admins, for a start :-). Oh, and it's Gforge, not Sourceforge (which has ceased to be free for years). >> Imho this would only make sense if integrating these two is hard, >> and if non-Debian projects are hosted on Alioth (I don't know). > > Yeah, I couldn't tell you why that feature is even enabled on > alioth. Because having it available doesn't hurt, and project admins can enable/disable trackers on their project as they see fit. > Do people actually use it? I certainly never check the tracker for > alioth projects I'm involved with; I just assume people will use the > Debian BTS instead. Some people do use it. Not many, admittedly: we have a total of about 3600 tracker items in the database. But since we have a few cases of upstream development hosted on Alioth, it makes sense to offer an alternative to the Debian BTS that not everyone likes. Roland. -- Roland Mas Bonjour, je suis un virus de signature. Propagez-moi dans la vôtre !
Re: Alioth Tracker: no correspondence to BTS?
On 7/10/06, Frans Pop <[EMAIL PROTECTED]> wrote: On Sunday 09 July 2006 21:29, Peter Samuelson wrote: > > I've just poked around a bit in Alioth for a project I'm working on > > and found a bug report with a bug number that has no resemblance to > > anything in BTS, quite contrary to my initial assumption. > > Yeah, the sourceforge software includes a primitive bug tracker which, > as far as I know, people don't really use on alioth. Note that the project admins can disable this (and other) feature. And if your going to reference non-debian bts bugs around Debian Community, why not prefix with a U, or an A? (Ubuntu and Alioth respectively), i.e. U#943242 (Whoops, forgot to CC it, sorry Frans) -- N Jones -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alioth Tracker: no correspondence to BTS?
Quoting Peter Samuelson ([EMAIL PROTECTED]): > Yeah, I couldn't tell you why that feature is even enabled on alioth. > Do people actually use it? I certainly never check the tracker for > alioth projects I'm involved with; I just assume people will use the > Debian BTS instead. We (iso-codes maintenance team and, more precisely Tobias Toedter) discovered that some people reported bugs in the Alioth BTS (or tracker?) without us even knowing about it..:-) The action has of course been to re-report these to the Debian BTS andshut down the feature. Of course, this makes me think that the feature should indeed be disabled by default in new projects. -- signature.asc Description: Digital signature
Re: Alioth Tracker: no correspondence to BTS?
On Sunday 09 July 2006 21:29, Peter Samuelson wrote: > > I've just poked around a bit in Alioth for a project I'm working on > > and found a bug report with a bug number that has no resemblance to > > anything in BTS, quite contrary to my initial assumption. > > Yeah, the sourceforge software includes a primitive bug tracker which, > as far as I know, people don't really use on alioth. Note that the project admins can disable this (and other) feature. pgpVsC5sx8YDr.pgp Description: PGP signature
Re: Alioth Tracker: no correspondence to BTS?
[Toni Mueller] > I've just poked around a bit in Alioth for a project I'm working on > and found a bug report with a bug number that has no resemblance to > anything in BTS, quite contrary to my initial assumption. Yeah, the sourceforge software includes a primitive bug tracker which, as far as I know, people don't really use on alioth. > Imho this would only make sense if integrating these two is hard, and > if non-Debian projects are hosted on Alioth (I don't know). Yeah, I couldn't tell you why that feature is even enabled on alioth. Do people actually use it? I certainly never check the tracker for alioth projects I'm involved with; I just assume people will use the Debian BTS instead. signature.asc Description: Digital signature
Re: Alioth Tracker: no correspondence to BTS?
also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.07.09.2017 +0200]: > I've just poked around a bit in Alioth for a project I'm working > on and found a bug report with a bug number that has no > resemblance to anything in BTS, quite contrary to my initial > assumption. Imho this would only make sense if integrating these > two is hard, and if non-Debian projects are hosted on Alioth (I > don't know). A reference would help. Is it maybe an Ubuntu bug? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system it may look like i'm just sitting here doing nothing. but i'm really actively waiting for all my problems to go away. signature.asc Description: Digital signature (GPG/PGP)
Alioth Tracker: no correspondence to BTS?
Hello, I've just poked around a bit in Alioth for a project I'm working on and found a bug report with a bug number that has no resemblance to anything in BTS, quite contrary to my initial assumption. Imho this would only make sense if integrating these two is hard, and if non-Debian projects are hosted on Alioth (I don't know). Any comments, please? Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
